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EXECUTIVE  SUMMARY  -  ASEM  FINAL  REPORT 

Background 

Loral  Federal  Systems  Company  (formerly  IBM  Federal  Systems  Company)  and  IBM 
Microelectronics  combined  efforts  in  an  Advanced  Research  Projects  Agency  (ARP A)  Application 
Specific  Electronic  Module  (ASEM)  contract  to  establish  low  volume.  Department  of  Defense 
(DoD),  application  access  to  IBM’s  high  volume  foundry  which  had  historically  been  a  captive 
supplier.  The  contract  called  for  development  of  design  kits  and  a  multi-entry  design  system, 
hybrid  (C4,  wire  bond,  and  TAB)  interconnect  technology  development  for  MCM-D,  sharing  IBM 
MCM  experience  with  others  in  the  ASEM  infrastructure,  and  demonstrating  capabilities  in  real 
applications. 

ASEM  General  Objectives 

This  contract  was  defined  as  part  of  ARPA's  efforts  to  fulfill  objectives  of  the  ASEM  Program  and 
more  globally  it’s  Packaging  Strategy. 

The  Packaging  strategy  is  made  up  of  four  major  points. 

•  Re-establish  U.S .  leadership  in  high  value-added  packaging  technologies. 

•  Exploit  packaging  technology  discontinuity  (single  chip  to  Multichip). 

•  Focus  on  end-product  markets  where  the  U.S.  has  a  strong  presence  (i.e.,  computers, 
telecommunications,  automotive,  aerospace). 

•  Establish  a  strong  domestic,  dual-use  merchant  infrastructure. 


The  ASEM  Program,  as  outlined  by  ARP  A,  has  five  main  program  objectives.  These  objectives 
are: 

•  Develop  advanced  MCM  technologies  to  meet  future  DoD  requirements. 

•  Reduce  non-recurring  engineering  (NRE)  cost  and  cycle  time  by  10  fold  with  first  pass 
success  on  designs. 

•  Reduce  the  total  recurring  module  cost  for  current  technologies  by  an  order  of  magnitude. 

•  Develop  applications  which  stimulate  demand  for  MCM  technology. 

•  Provide  DoD  access  to  robust  manufacturing  capabilities . 

The  resources  for  execution  of  this  contract  came  from  two  corporations,  Loral  Federal  Systems 
Company  and  IBM  Microelectronics.  The  general  description  of  the  contribution  of  the  companies 
were: 


•  Loral  Federal  Systems,  Manassas,  VA:  Loral  has  extensive  experience  managing 
technology  development  contracts  with  the  government.  The  program  management  and 
contract  fulfillment  was  the  responsibility  with  Loral.  Software  skills  from  Loral  were 
also  used  to  support  contract  deliverables 

•  IBM  Microelectronics,  East  Fishkill,  NY:  IBM  offers  the  DoD  the  world's  largest  MCM 
production  facility  where  a  sizable  investment  has  been  made  in  microelectronics 
packaging  for  both  single  chip  and  Multichip  products.  Personnel  from  IBM  were 
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temporarily  transferred  to  Loral  to  support  technical  management,  technology 
development,  and  design  deliverables. 

ASEM  Contract  MDA972-93-C-011  Objective 

The  specific  objective  of  this  contract  is  to  provide  low  volume  (low-cost/volume  QTAT)  access 
to  a  high  volume,  commercial  MCM  foundry,  at  IBM.  This  lead  to  the  generation  of  a  list  of  tasks 
and  milestones  that  were  defined  and  achieved  to  help  ARPA  achieve  its  objectives.  In  addition  to 
providing  foundry  access,  effort  was  also  put  towards  cycle  time  reduction  and  lowering  costs. 

The  rest  of  this  section  briefly  describes  the  specific  tasks  and  accomplishments,  all  of  which  were 
delivered  on  or  ahead  of  schedule. 

Tasks  and  Accomplishments 

The  following  are  the  major  task  listings  from  the  statement  of  work  along  with  the 
accomplishments  achieved  over  the  course  of  the  contract. 

Provide  design  kits  and  customer-foundry  interfaces  to  support  multi-entry  point 
designs 

Trade-off  tools  requirements  were  defined  and  a  list  of  existing  tools  were  evaluated  against 
those  requirements.  MCC's  MSDA  tradeoff  tool  offering  comes  closest  to  meeting  the 
requirements  for  an  MCM  tradeoff  tool.  However,  major  deficiencies  remain  to  be  addressed. 
These  include  establishing  a  comprehensive  component  library  and  developing  standard 
interfaces  to  detailed  EDA  tools.  Recommendations  for  future  trade-off  tool  development  are 
also  included  in  the  details. 

The  foundry’s  capability  to  support  multi-entry  design  points  was  demonstrated  (both  logic 
and  physical  design  entry  into  the  foundry).  Physical  entry  is  Customer  driven  logic  and 
physical  design  from  Cadence  and  Mentor  Graphics  tools.  In  this  scenario  IBM  would  simply 
deliver  the  module  designed  by  the  customer.  In  Logic  entry,  the  customer  completes  the  logic 
design  and  passes  the  specifications,  netlist  information,  and  constraints  to  IBM.  The  IBM 
foundry  then  completes  the  physical  design  and  fabricates  the  module. 

To  enhance  customer  access  to  the  foundry,  MCM-D  kits  were  developed  for  the  Cadence  and 
Mentor  Graphics  design  tools.  These  supported  mainly  physical  design  but  also  provided  some 
support  for  the  logic  design  and  specification  phases  of  MCM  design. 

With  test  being  such  a  significant  aspect  of  MCM  development,  foundry  MCM  test  experience 
and  recommendations  were  compiled  in  a  ‘Testability  Strategy  and  Guidelines’  document. 

This  strategy  was  implemented  and  found  to  be  effective  in  dealing  with  the  demonstration 
vehicles  produced  during  the  contract  period. 

The  contract  also  supported  study  of  the  release  process  of  custom  MCMs  at  IBM  to  facilitate 
reduction  of  cycle  time  and  errors.  The  information  developed  assisted  in  the  redefinition  of 
release  for  prototypes  such  that  manufacturability  checking  and  release  was  complete  in  a  few 
days  instead  of  weeks. 

Another  accomplishment  was  the  integration  and  automation  of  certain  design  and  release  steps 
in  a  framework.  This  was  initiated  in  ongoing  efforts  to  reduce  cycle  time  and  NRE  within  the 
process. 
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Develop  hybrid  (C4/wire  bond/TAB)  die  interconnect  procedures  on  MCM-D 
substrate. 

Mixed  interconnect  technology  had  been  seen  as  a  necessity  for  the  emerging  MCM  market 
since  die  have  to  come  from  a  variety  of  manufacturers  and  these  die  may  not  always  be 
available  in  the  format  desired. 

Mixed  interconnect  technology  (C4/wire  bond/TAB)  on  ceramic  substrates  had  already  been 
demonstrated  by  IBM,  but  the  same  capability  was  not  available  on  MCM-D.  An  MCM-D 
module  was  designed  that  incorporated  standard  wire  bond  die  with  280  pads  on  a  2  mil  pitch, 
an  advanced  TAB  part  with  328  leads  on  a  2  mil  pitch,  a  C4  (flip  chip)  die  with  2401  pads, 
and  two  inverter  chips  to  form  a  ring  oscillator.  It  was  encapsulated  with  a  hermetic  kovar  cap. 
A  number  of  passive  structures  were  also  included  in  the  design  to  measure  technology 
characteristics. 

In  developing  this  module,  a  metallurgy  structure  was  developed  that  simultaneously  supported 
all  three  types  of  interconnect  technology,  thus  cost  reducing  this  technology  capability. 

Modules  were  electrically  and  environmentally  tested  at  IBM  and  40  pieces  were  delivered  to 
RELTECH  for  their  evaluation.  All  results  met  or  exceeded  expectations. 

Collaborate  with  industry/consortia  to  formulate  standards  for  CAD,  KGD, 
MCM/Packaging  applications  and  test 

A  number  of  infrastructure  activities  were  supported  during  the  contract  including  MCC 
known  good  die  (KGD)  studies,  ASEM  Alliance  MCM  standardization  efforts  (in  Foundry 
Interfaces  specification,  EDIF  activities,  and  Design  kit  activities),  and  industry  conferences. 
Many  papers  were  presented  on  various  topics  including  materials  development,  reliability, 
MCM  test  methodology,  design  kit  development,  and  application  successes.  The  details  can  be 
found  in  the  Infrastructure  section  of  the  full  report. 

Fabricate  and  test  a  MCM  to  demonstrate  a  full-service  foundry  capability. 

Three  MCMs  were  developed  under  the  contract.  A  SuperSparc  module  was  developed  with 
Sim  Microsystems  and  a  ‘CL Ay’  Processor  module  was  developed  with  National 
Semiconductor.  These  two  modules  demonstrated  the  logic  design  entry  path  into  the  foundry. 
A  data  transfer  module  was  built  for  McClellan  Air  Force  Base  (Air  Logistics  Center)  which 
demonstrated  the  physical  design  entry  path. 

Both  the  SuperSparc  and  ‘CLAy’  modules  began  with  die  developed  for  wirebond  applications 
and  converted  to  flip  chip  form  factors  to  reduce  module  size  and  enhance  thermal  performance. 

SuperSparc  module  was  successfully  fabricated,  assembled  and  interconnect  tested.  Module 
functional  test  was  not  requested  by  Sun. 

The  ‘CLAy’  module  was  successfully  fabricated  and  assembled.  National  Semiconductor  did 
not  require  functional  or  interconnect  test. 

The  data  transfer  module,  for  McClellan  Air  Force  Base,  required  die  in  the  wirebond  format. 
This  module  was  successfully  fabricated,  assembled  and  tested  in  less  than  8  weeks.  Some 
functional  test  was  possible  since  the  Customer  supplied  the  necessary  patterns. 

Summary 

All  contract  tasks  were  completed  successfully,  on-time,  and  to  cost.  Significant  progress  was  also 
shown  towards  achieving  the  global  ARPA  objectives  for  the  ASEM  program. 
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STATEMENT  OF  WORK  CROSS  REFERENCE 

This  section  is  intended  to  help  direct  comparisons  of  the  ASEM  Contract  statement  of  work  to  this 
final  report.  The  outline  of  this  section  directly  corresponds  to  the  statement  of  work  with  the  items 
having  identical  task  numbers.  Each  section  introduces  the  requirements,  repeats  the  statement  of 
work,  describes  the  approach  and  methodology  used  in  satisfying  the  requirements,  and  refers  to  the 
sections  of  the  final  report  that  demonstrate  that  the  requirements  have  been  satisfied. 

Design  System  (Task  2.1.11 

Design  Kits,  Interfaces,  Tradeoff  Tools,  and  Test  (Task  2.1.1.1) 

Design  Kits  (Task  2.1.1.1.1) 

Requirements 

In  order  to  achieve  low  volume  access  to  a  high  volume  foundry,  reduced  design  cycle  time  and 
non-recurring  engineering  costs  (NRE),  and  to  routinely  achieve  first  pass  success  on  new  designs, 
design  kits  were  developed. 

Design  kits  describe  information  to  improve  the  effectiveness  of  an  engineer  in  understanding  and 
implementing  solutions  in  a  particular  technology  that  will  be  built  at  an  ASEM  foundry.  The 
information  needs  to  be  both  general,  as  in  a  technology  text,  and  specific,  as  in  design  tool 
parameters  to  force  conformance  to  technology  requirements.  This  combination  allows  for  quick 
transfer  of  engineering  knowledge,  definition  of  customer-foundry  interface  requirements,  and 
instantaneous  tool  set  up  to  speed  design  decisions  and  implementation. 

From  ASEM  Contract;  MDA972-93-C-0011  (SOW  2.1. 1.1): 

1)  Create  MCM-D  electronic  design  kits.  The  design  kits  will  be  based  on  standards  and  will  be  as 
CAD  tool  independent  as  possible.  The  design  kits  will  contain  different  sets  of  information  for  the 
physical  design  level,  the  logic  design  level,  the  specification  level  and  the  trade  off  tool  level. _ 

Approach 

MCMs,  like  early  ASICs,  have  been  used  for  a  long  time  by  companies  who  developed  experts 
who  were  capable  of  understanding  and  implementing  solutions  in  this  beneficial  technology. 
However,  for  MCMs  to  become  a  general  solution,  a  method  had  to  be  developed  to  easily  convey 
the  information  needed  to  the  general  design  engineering  community.  For  this  objective,  the  MCM 
Design  Kit  was  developed.  Is  was  presumed  that  if  design  kits  were  successful,  more  design 
engineers  would  be  able  to  design  in  MCM  technology  . 

Since  no  literature  existed  on  MCM  design  kits,  discussions  were  held  with  Commercial  Electronic 
Design  Automation  (EDA)  companies,  MCM  Foundries,  and  MCM  Design  Engineers.  For  the  kit 
to  be  successful  it  was  decided  that  the  most  important  information  to  be  verified  was  the 
information  that  supports  physical  design.  If  physical  design  was  not  possible,  all  information 
developed  for  the  other  design  phases  would  be  much  less  useful. 

To  bound  the  effort  in  the  contract,  the  primary  technology  was  chosen  to  be  MCM-D.  To  bound 
the  problem  of  design  tools  to  be  addressed,  two  tool  sets  were  chosen  for  the  MCM  design  kits 
(CADENCE™  and  Mentor  Graphics  Corporation^).  The  Cadence  and  Mentor  Graphics  tool  sets 
were  documented  in  the  'Design  System  Requirements'  report. 

A  design  kit  specification  was  desired  to  provide  a  standard  description  of  what  was  to  be  in  a  kit. 
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Finally,  the  kit  would  be  distributed  to  customers  for  use  and  feedback  and  initial  updates  to  the  kit 
would  be  supported.  Full  usefulness  of  these  kits  is  dependent  on  the  foundry's  continued  offering 
of  the  products  supported  by  the  developed  design  kits  and  customer  response  to  the  kits. 

Cross  Reference  Sections 
The  results  of  this  activity  is  described  in  sections: 

2.2.  Design  Kits 

2.2.1.  Design  System  Requirements 

2.2.2.  MCM-D  Design  Kit  Specification 

2.2.3.  Cadence  MCM-D  Design  Kit 

2.2.4.  Mentor  Graphics  MCM-D  Design  Kit 

2.2.5.  Design  Kit  Section  Conclusions 

2.2.6.  References 

Design  System  Interfaces  (Task  2.1.1.L2) 

Requirements 

Design  Interfaces  are  the  interfaces  between  phases  and  tool  sets  used  in  design.  They  require 
specific  sets  of  information  to  be  exchanged  for  the  interface  to  operate  efficiently.  For  software 
tools  to  work  efficiently,  the  format  of  the  information  also  needs  to  be  specifically  defined.  In 
order  to  reduce  design  cycle  time,  and  the  corresponding  NRE,  these  interfaces  needed  to  be 
studied,  defined,  and  exercised  to  prove  the  effectiveness  of  the  definitions.  The  scope  of  this  effort 
mainly  supported  the  interface  between  completed  physical  design  and  the  foundry,  but  also 
allocated  some  effort  to  the  logic  to  physical  design  phase,  and  minimally  addressed  the 
specifications  interface  to  logic  design. 

From  ASEM  Contract;  MDA972-93-C-001 1  (SOW  2.1. 1.1):  " 

2)  Design  and  document  interfeces  needed  between  the  customer  and  the  IBM  foundry;  a.)  at  the 
specification  level,  b.)  at  the  logic  design  level,  and  c.)  at  the  physical  design  level.  Develop  test 
cases  to  cover  entry  into  the  foundry, _ 

Approach 

This  work  was  initiated  with  an  understanding  of  the  IBM  foundry  requirements  and  preferences. 

It  was  also  deemed  important  to  try  to  define  an  interface  that  customers  would  recognize  as 
similar  across  many  MCM  foundries.  For  this  reason  there  was  significant  interaction  between  the 
interface  activity  and  the  ASEM  Customer  Foundry  Working  Group  associated  with  the  MCC 
ASEM  contract. 

Another  starting  point  for  the  interfaces  was  the  current  experience  base  of  Gerber  and  GDS2  as 
formats  for  artwork  data  exchange.  This  in  conjunction  with  industry  standards  such  as  EDIF 
were  to  be  the  focus  of  the  study.  These  standard  formats  were  chosen  in  order  to  help  customers 
see  'standardization'  similarities  of  the  interfaces  regardless  of  the  MCM  foundry  they  may  be 
choosing. 

With  these  situations  in  mind,  the  requirements  were  documented  in  the  “IBM  MCM  Foundry 
Interface  Specification”  CLIN  0002AG.  Given  a  documented  interface,  test  cases  were  developed 
to  help  further  understand  and  demonstrate  the  capabilities  described  in  the  interface  specification. 
Focus  was  on  the  Logic  and  Physical  interfaces  because  these  were  the  ones  that  needed  most 
enhancement  to  support  the  commercial  market. 
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Cross  Reference  Sections 
The  results  of  this  activity  is  described  in  sections: 

2.3.  Design  System  /  Foundry  Interfeces 

2.3.1.  Communication  Channels 

2.3.2.  Specification  Interface 

2.3.3.  Logic  Interface 

2.3.4.  Physical  Interface 

2.3.5.  Conclusions 

(see  the  section  on  the  demonstration  of  the  release  section  2.4.3  for  operational  results) 

Trade-off  tools  (T ask  2. 1. 1.  L  3) 

Requirements 

Trade  off  tools  are  used  to  help  make  early  decisions  about  specific  alternatives  and  their  impact  to 
product  objectives,  even  during  the  product  definition  phase  of  a  program.  For  this  reason  it  was 
determined  that  an  investigation  of  existing  tools  should  be  made  in  order  to  determine  the  degree  to 
which  they  could  be  supported  near  term. 

From  ASEM  Contract;  MDA972-93-C-00 1 1  (SOW  2. 1 . 1 . 1): 

3)  Study  Trade-off  Tools,  specifically  those  of  (a)  MCC,  (b)  Mentor,  (c)  Cognition,  (d) 

"SUSPENS",  a  tradeoff  tool  from  Stanford  University,  (e)  "AUDiT",  a  tradeoff  tool  from 
Cornell  University  and  (f)  "PEPPER",  an  IBM  tradeoff  tool,  and  recommend  for  ARPA  approval 
the  best  tool  selection  for  use  in  the  foundry  interface. _ 

Approach 

The  study  identified  various  trade  off  tools,  described  requirements  for  the  tools,  established  a  list 
of  domains  that  were  important  to  MCMs,  evaluated  the  tools,  and  described  their  effectiveness. 

The  general  domains  of  the  study  were  cost,  turn  around  time,  substrate  and  chip  selection, 
package  selection,  power  dissipation,  frequency  performance,  packaging  delays,  testability, 
reliability  and  manufacturability. 

Cross  Reference  Sections 
The  results  of  this  activity  is  described  in  sections: 

2.1.  Trade-off  tools 

2.1.1.  Introduction 

2.1.2.  Trade-Off  Tool  Requirements 

2.1.3.  Evaluation  Domain  Overview 

2.1.4.  Tool  Evaluation  Summary 

2.1.5.  Tool  Effectiveness  Results 

2.1.6.  Conclusions 

Testability  Strategy  and  Guidelines  (Task  2. 1.1. 1.4) 

Requirements 

From  ASEM  Contract;  MDA972-93-C-00 1 1  (SOW  2. 1 . 1 . 1): 

4)  Develop  a  testability  strategy  and  guidelines  to  support  entry  points  into  the  IBM  foundry  at 

various  design  levels. _ 


Approach 

The  approach  used  to  meet  the  objectives  was  to  develop  a  strategy  which  was  appropriate  to  the 
business  and  customer  environment  with  respect  to  design  ownership  and  tasks.  The  second 
element  of  the  approach  to  meeting  our  goals  was  to  install  appropriate  tooling  and  business 
processes  to  validate  the  selected  test  methodology.  The  third  element  in  our  approach  was  to 
benchmark  progress  in  lowering  our  turn  around  time  (TAT)  and  NRE  cost  by  monitoring  the 
effort  spent  in  performing  test  on  real  MCMs.  The  results  of  the  bench-marking  actual  application 
vehicles  would  verify  that  the  implemented  test  strategy  was  in  fact  producing  lowered  TAT  and 
costs. 

Cross  Reference  Sections 
The  results  of  this  activity  is  described  in  sections: 

3.0  MCM  Test 

3.1.  Test  Environment 

3.1.1.  ASEM  Testing  Challenges 

3.1.2.  MCM  Test  Categories 

3.1.3.  Captive  vs.  OEM  Foundry  Test  Environment 

3.2.  Test  Methodology 

3.2.1.  Assumptions 

3.2.2.  Basic  Approach:  Distributed  Testing 

3.2.3.  Implementation  Aspects  of  Test 

3.2.4.  Diagnostic  Implications 

3.2.5.  Methodology  Conclusions 

3.3.  Interconnect  Test  Implementation 

3.3.1.  Software  Platform 

3.3.2.  Fixturing  Hardware 

3.3.3.  Database 

3.3.4.  Test  Vector  Generation 

3.3.5.  Test  Database  Verification 

3.3.6.  Interconnect  Test 

3.3.7.  Test  Implementation  Conclusions 

3.4.  Known  Good  Die(KGD) 

3.4.1.  KGD  Process 

3.4.2.  Parameters  for  KGD  Implementation 

3.4.3.  Known  Good  Die  Test  and  Conclusions 

3.5.  Data  Integrity 

3.5.1.  MCM  Environment 

3.5.2.  Data  Integrity  Methodology 

3.5.3.  Data  Integrity  Conclusions 

3.6.  MCM  Test  Results 

3.6.1.  Demonstration  Vehicle  Test  Summary 

3.6.2.  Benchmark  Results 

3.7.  MCM  Test  Conclusions 

3.8.  References 

Direct  Release  (Task  2. 1.1.2) 

IBM  had  developed  a  release  system  strongly  directed  towards  the  standard  module  families  used 
by  many  of  the  internal  IBM  product  lines  that  the  foundry  traditionally  supported.  This  focused 


on  quick  release  of  routing  interconnect  layers  that  were  compatible  with  pre-designed 
redistribution  and  power  layers  for  a  given  chip  set. 

This  existing  release  system  was  not  suited  to  handle  the  custom  MCMs  typically  required  in  the 
merchant  market.  Custom  MCMs  require  that  all  layers  of  an  MCM  be  designed  and  released 
concurrently.  In  addition,  specifications  and  drawings  are  generated  concurrently  with  the  design 
so  traditional  work  sequencing  that  was  incorporated  into  the  IBM  standard  module  family 
release  process  appeared  as  product  delays  and  bureaucracy  in  the  custom  MCM  environment. 
For  this  reason  activity  was  defined  to  enhance  the  release  process  to  meet  the  ASEM  goals  of 
providing  low  volume  access  to  a  high  volume  foundry,  reducing  cycle  times  and  NRE,  and 
routinely  achieving  first  pass  success  on  designs. 

Requirements 

From  ASEM  Contract;  MDA972-93-C-0011  (SOW  2. 1.1. 2): 

1 . )  Integrate  direct  release  tools  to  reduce  cycle  time  by  fifty  percent  and  reduce  direct  release 
defects  by  fifty  percent  by  developing  the  system  architecture  and  additional  tools  needed  to 
support  objectives.  Encapsulate  all  tools  into  the  IBM  Application  Framework. 

2. )  Install  and  demonstrate  system  at  IBM's  E.  Fishkill  facility. _ 

Approach/Method 

The  approach  was  to  evaluate  the  custom  MCM  and  prototype  requirements  in  relationship  to  the 
existing  release  capabilities.  With  the  requirements  defined,  an  architecture  could  be  proposed  that 
would  be  a  model  of  an  ideal  release  system.  The  task  envisioned  that  improvements  could  only 
come  in  a  framework  integrated  environment,  another  alternative  was  identified  later  in  the 
program  which  led  to  a  more  cost  effective  approach  towards  achieving  the  objective. 

Implementation  of  the  release  system  referenced  the  information  uncovered  in  the  evaluation  phase 
and  the  ideal  release  architecture.  Regular  measurement  of  the  release  problems  created  the  right 
focus  and  priority  for  solving  current  OEM  release  problems. 

The  system  was  exercised  to  demonstrate  the  increased  effectiveness  of  the  release  system. 

Chapter-Section  Cross  Reference 
The  results  of  this  activity  is  described  in  sections: 

2.4.  Direct  Release 

2.4.1.  Introduction 

2.4.2.  Architecture  and  Objectives 

2.4.3.  Implementation 

2.4.4.  Demonstration 

2.4.5.  Direct  Release  Conclusions 

Framework  (Task  2. 1.1.3) 

The  framework  activity  in  the  contract  was  identified  because  of  the  recognized  importance  of  data 
integrity  and  process  management  in  assuring  first  pass  design  and  release  success.  This  activity 
also  recognized  that  the  design  and  release  process  at  the  beginning  of  the  contract  operated  on 
information  from  a  number  of  different  platforms  and  sources  and,  from  the  custom  MCM 
perspective,  many  of  the  steps  in  the  process  were  performed  using  manual  (data  transfers  and 
paper  driven)  point  tools.  The  intent  was  to  use  some  framework  to  begin  to  link  and  automate  the 
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steps  of  the  process.  By  linking  and  automating  pieces  of  the  process,  it  would  not  only  run  fester 
but  reduce  errors  and  learning  curves  associated  with  staffing  these  processes. 

Requirements 

From  ASEM  Contract;  MDA972-93-C-0011  (SOW  2. 1.1. 3): 

1. )  Complete  and  document  IBM  USER  Framework  communication  message  classes  necessary  to 
complete  ffamework/framework  communications. 

2. )  Demonstrate  ffamework/framework  communications  between  the  IBM  design  tool  set  and 

direct  release  system  and  the  Cadence  design  tool  set  at  the  specification,  logic,  and  physical  design 
levels. _ 

Approach/Method 

Utilizing  a  framework  was  considered  an  activity  that  needed  evaluation  because  of  some  primary 
benefits  of  reduced  cycle  time  and  errors.  Framework  integration  allows  a  reduction  in  the 
distribution  of  cycle  time  and  errors  between  ‘experienced’  personnel  and  ‘novices’  by  helping 
novices  through  the  process  and  automating  various  process  steps  for  all  personnel. 

Initial  work  involved  investigating  Framework  capability  and  estimating  efforts  and  pay  back 
involved  in  integrating  the  design  and  release  process  in  a  framework. 

Requirements  and  architecture  descriptions  were  created  which  defined  an  ideal  integrated  design 
system.  This  was  written  relative  to  IBM  ProFrame  capabilities  with  CFI  2.0  extensions.  Then 
alternatives  were  reviewed  against  that  definition. 

There  were  three  areas  to  consider: 

1 .  Framework  capabilities  and  extendibility 

2.  Process  flexibility  and  maintainability  in  the  Framework 

3 .  Maximizing  industry  benefit  from  the  integration  activity 

Conclusions  drawn  from  this  activity  determined  an  integration  approach  which  was  demonstrable. 

Cross  Reference  Sections 
The  results  of  this  activity  is  described  in  sections: 

2.5.  Framework 

2.5.1.  Introduction 

2.5.1.  Framework  Evaluations 

2.5.2.  Implementation 

2.5.3.  Conclusions 


Hybrid  (C 4,  Wirebond,  and  Tab)  Interconnect  Technology  (Task  2.2.  n 
MCM  Test  Vehicle  (Task  2.2. 1.1) 

Requirements 

From  ASEM  Contract;  MDA972-93-C-001 1  (SOW  2.2.1):  ~  — 

2.2. 1  C4,  Wirebond  &  TAB  Integration. 

This  task  is  to  establish  and  demonstrate  the  processes  required  to  mix  C4  finished  die,  TAB  and  Wire- 
Bond  chips  onto  MCM-D  thin  film  substrates. 

This  task  will  include  the  following: 

1 .  MCM  Test  Vehicle 

Design  and  build  a  Technology  (Process)  Demonstration  Vehicle  (TDV)  consisting  of  a  thin-film  MCM- 
D  substrate  with  C4,  wirebond  and  TAB  attached  chips  co-resident  upon  it.  Electrical  testing  to  validate 
the  attach  processes  will  be  performed. 

2.  Physical  Analysis 

Perform  a  destructive  physical  analysis  on  the  Technology  Demonstration  Vehicle.  Quality  and  reliability 
tests  will  be  performed  on  the  attach  processes.  The  test  results  will  be  documented  in  a  physical  analysis 
report. 

3.  Qualification  (UN-PRICED  OPTION) 

IBM  will  perform  a  qualification  of  the  combined  die  attach  processes  using  the  Technology 
Demonstration  Vehicle.  Qualification  hardware  and  test  results  will  be  provided. 

Approach/Method 

The  approach  is  fairly  well  defined  by  the  statement  of  work.  Work  items  1.)  and  2.)  correspond  to 
the  similar  section  headings.  Report  section  4.3  is  a  summary  of  activities  oriented  towards  the 
ASEM  cost  reduction  objective. 

Cross  Reference  Sections 

The  results  of  this  activity  is  described  in  sections: 

4.0  Hybrid  (C4,  Wirebond,  and  Tab)  Interconnect  Technology 

4.1.  MCM  Test  Vehicle  (Technology  Demonstration  Vehicle) 

4.1.1.  MCM  Test  Vehicle  -  Methods 

4. 1 .2.  MCM  Test  Vehicle  -  Results 

4.2.  Physical  Testing 

4.2.1.  Physical  Testing  -  Methods 

4.2.2.  Physical  Testing  -  Results 

4.3.  Cost  Reduction  Results 

4.3 . 1 .  Cost  Reduction  -  Methods 

4.3.2.  Cost  Reduction  -  Results 

4.4.  Conclusions 


Infrastructure  Support  (Task  2.3. 1} 

Infrastructure  activities  were  structured  to  insure  that  knowledge  was  shared  with  the  rest  of  the 
industry. 

Requirements 

From  ASEM  Contract;  MDA972-93-C-0011  (SOW  2.3.1): 

IBM  will  actively  participate  with  MCM  industry  groups  and  consortia  to  develop  and  formulate 
standards  for  Known-Good-Die,  CAD,  MCM  packaging,  test  and  reliability. 

1 . )  IBM  will  participate  in  government  and  industry  sponsored  committees.  IBM  intends  to 
perform  a  leadership  role  in  the  area  of  test,  packaging,  and  flip  chip  reliability  in  concert  with  the 
IEEE  Test  Standard  Committee,  the  JEDEC  Solid  State  Products  Engineering  Committee  and  the 
NASA-  Industry  Design  Standards  Group,  respectively. 

2. )  IBM  will  participate  as  a  core  team  member  of  the  proposed  MCC  ASEM  Technology 
Standards  and  Specifications  Alliance  to  address  MCM  issues.  IBM  chair  focus/working  group(s) 
and  will  take  the  lead  role  in  drafting  standards  for  the  ASEM  Foundry  group.  IBM  will  also  work 
with  the  MCC  KGD  Study  Group  and  will  coordinate  the  implementation  of  KGD  requirements. 
Approach/Method 

The  approach  is  fairly  well  described  in  the  statement  of  work.  There  was  significant  participation 
in  a  variety  of  organizations.  Leadership  was  shown  in  many  of  these  organizations  including 
chairing  the  ASEM  Customer/Foundry  working  group  of  the  ASEM  Alliance.  Details  of  the 
various  contributions  are  segmented  by  subject  matter. 

Cross  Reference  Sections 

The  results  of  this  activity  is  described  in  sections: 

5.0  Infrastructure 

5.1.  Application  Demonstration 

5.1.1.  ISI/MOSIS 

5.1.2.  Mayo  Foundation,  Special  Purpose  Processor  Development  Group. 

5.1.3.  Hardware  Standards 

5.1.4.  Industry  Conferences  and  Meetings 

5.1.5.  Application  Demonstration  Conclusions 

5.2.  CAD  Infrastructure 

5.2.1.  ASEM  Alliance  Results  /  Standards 

5.2.2.  Other  organization  Support 

5.2.3.  Industry  Conferences  and  Meetings 

5.2.4.  CAD  Infrastructure  Conclusions 

5.3.  Module  Test  /  Known  Good  Die 

5.3.1.  MCM  Test 

5.3.2.  Known  Good  Die 

5.3.3.  Other  organization  Support 

5.3.3.  Module  Test  /  Known  Good  Die  Conclusions 

5.4.  Interconnection  Technology 

5.4.1.  Industry  Conferences  and  Meetings 

5.4.2.  Other  organization  Support 

5.4.3.  Interconnection  Technology  Conclusions 

5.5.  Infrastructure  Conclusions 
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Demonstration  Vehicles  (Task  2.4.11 
Requirements 


From  ASEM  Contract;  MDA972-93-C-001 1  (SOW  2.4.1): 

2.4.1  DEMONSTRATION. 

IBM  will  incorporate  activities  from  the  above  three  tasks  into  an  application  demonstration 
vehicle. 

This  task  will  include  the  following: 

1 .  IBM  will  survey  industry  and  government  programs  program  in  the  areas  of  HPCC,  HDS  and 
military  programs  and  will  identify  candidates. 

2.  IBM  will  meet  with  potential  application  partners  to  establish  a  demonstration  plan  for  DARPA 
review  and  approval.  This  plan  will  include; 

a.  application  description 

b.  hardware  description 

c.  description  of  demonstration  system 

d.  description  of  the  Known-Good-Die,  Design-for-Test  plan. 

3.  IBM  will  perform  an  full  service,  foundry  demonstration  and  will  provide  prototype  hardware 
and  documentation. 

4.  IBM  will  accept  a  design  and  will  implement  the  design  on  a  demonstration  prototype  MCM 
module. 

5.  IBM  will  assemble  and  test  the  MCM  using  C4/TAB/WB,  as  required. 

6.  IBM  will  demonstrate  the  MCM  in  an  application  environment,  as  required. _ 

Approach 

The  approach  is  fairly  well  described  by  the  statement  of  work.  In  order  to  see  improvements  in  a 
more  timely  fashion,  an  incremental  demonstration  approach  was  taken  that  spread  demonstrated 
improvements  across  a  number  of  vehicles. 

Statement  of  work  items  map  to  correspondingly  named  sections  for  items  1.)  the  survey  and  2.) 
the  application  plan.  The  3.)  foundry  service  is  demonstrated  by  the  Sun  and  National 
Semiconductor  demonstrations.  The  4.)  accepted  design  is  demonstrated  by  the  McClellan  Air 
Force  Base  (AFB)  Air  Logistics  Center  (ALC)  module.  The  5.)  assemble  and  test  is  demonstrated 
in  die  Sim  and  McClellan  AFB  ALC  demonstration.  Finally,  6.)  application  environment  was 
demonstrated  in  the  test  of  the  Sun  module. 

Cross  Reference  Sections 

The  results  of  this  activity  is  described  in  sections: 

6.0.  Application  Demonstration 
6.1.  Customer  Survey 
6.1.1.  Selection  Criteria 
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6.1.2.  Methods  of  Customer  Contact 

6.2.  Selected  Applications  Overview 

6.3.  Sim  Microsystems 
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1.0  INTRODUCTION 

The  content  of  this  document  satisfies  the  requirements  of  line  item  0002AU  -  ASEM  Final 
Technical  Report  which  is  described  as: 

This  report,  prepared  in  accordance  with  DATA  Item  DI-MISC-8071 1,  shall  document  the 
results  of  the  complete  effort.  Title  pages  shall  included  a  disclaimer  worded...  (see 
Preface) 

The  Final  Technical  Report  summary  shall  include: 

Task  Objectives 
Technical  Problems 

General  Methodology  (i.e.,  literature  review,  laboratory  experiments,  surveys,  etc.) 
Technical  Results 

Important  Findings  and  Conclusions 
Significant  Hardware  Development 
Special  Comments 
Implications  for  Further  Research 
Standard  Form  298,  September  1988 

This  introduction  is  meant  to  give  readers  an  understanding  of  the  organization  of  this  document. 
This  final  technical  report  was  written  from  a  compilation  of  reports  delivered  over  the  course  of 
the  ASEM  Contract  which  was  roughly  between  January  1993  and  December  1994.  Some  of  the 
sections  are  direct  copies  of  information  from  the  individual  reports.  Where  necessary,  information 
bridges  were  written  to  tie  separately  written  texts  together  for  a  more  readable  text. 

Each  section  is  written  to  be  readable  within  itself  for  people  interested  solely  in  the  section 
content.  However,  a  reader  will  be  referred  to  other  sections  for  details  determined  to  be  only 
loosely  linked  to  the  main  subject  of  the  section  or  when  information  seems  too  repetitious. 

1.1  Objectives 

ARPA  set  a  number  of  specific  goals  for  the  ASEM  program.  Globally,  the  objective  is  to  reduce 
development  costs  and  design-to-product-delivery  cycle  times  by  a  factor  of  10  from  the  1992  state 
of  the  art. 

1.1.1  MCM  Environment 

MCMs  have  been  used  by  IBM  and  others  in  the  industry  for  over  twenty  years.  MCM  usage  was 
possible  because  of  engineers  in  these  companies  who  specialized  in  understanding  the  technology 
and  tools  necessary  to  make  MCMs  effective  for  their  product  needs.  Today,  a  wider  range  of 
products  are  finding  MCM  technology  attractive  for  its  competitive  advantages. 

Wider  use  of  MCMs  was  necessary  to  bring  down  MCM  costs  and  cycle  times.  Also,  lower  costs 
and  shorter  cycle  times  were  necessary  to  bring  in  additional  applications.  Work  was  pursued  to 
improve  both  these  situations. 

1.1.2  Specific  MCM  Focus  Areas 

The  specific  objective  of  this  contract  is  to  provide  low  volume  (low-cost/volume,  quick  turn 
around  time  (QTAT))  access  to  a  high  volume,  commercial  MCM  foundry,  at  IBM.  In  addition  to 
providing  access,  effort  was  also  put  towards  achieving  the  objectives  of  reducing  cycle  time  and 
cost. 
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1. 1.2.1  Foundry  Access 

Enabling  multi-use  entrance  (military,  commercial,  and  university;  chip,  substrate,  and  package 
supply)  to  the  foundry  via  industry  standard  interfaces. 

Provide  DoD  access  to  robust  manufacturing  capabilities. 

1. 1.2.2  Cycle  time 

Limiting  turn-around  time  to  1  month,  or  less. 

Reducing  design  to  product  cycle  time  by  10  fold. 

Routinely  achieving  first-pass  success  on  new  designs. 

1.1.2.3  Cost 

Ensuring  that  non-recurring  engineering  costs  do  not  exceed  $25K  per  design. 

Reduce  the  total  recurring  module  cost  for  current  technologies  by  an  order  of  magnitude. 

1.2  Organization 

1.2.1  Technical  Areas 

The  overview  of  the  program  and  the  intentions  of  ARPA  can  be  seen  from  the  Executive 
Summary  that  precedes  this  section. 

Sections  of  the  report  detail  the  results  and  experience  gained  as  a  result  of  the  activity.  As  seen  in 
the  table  of  contents  the  major  topics  are: 

•  Design  System 

•  MCM  Test 

•  Hybrid  (C4,  Wirebond,  and  Tab)  Interconnect  Technology 

•  Infrastructure 

•  Application  Demonstration 

•  Overall  Conclusions 

1.2.2  General  Descriptions 
1.2.2.1  Design  System 

This  section  compiles  a  variety  of  tasks  related  to  design  requirements,  methodologies,  and  tools. 
The  specific  subsections  are: 

•  Trade  Off  Tools  -  the  study  of  the  tools  that  were  available  at  the  beginning  of  the  contract 
and  their  capabilities  to  assist  in  design  decisions. 

•  Design  Kits  -  the  kits  developed  to  support  the  IBM  MCM-D  technology  in  the  Mentor 
Graphics  and  Cadence  design  tool  suites.  Design  tool  requirements  and  a  kit  specification 
are  also  presented. 

•  Interfeces  -  the  definition  of  foundry  interfaces  for  entry  into  the  foundry  at  a  completed 
specification,  completed  logic  design,  and  completed  physical  design  state. 

•  Direct  Release  -  the  study  of  product  release  requirements  and  improvements  that  were 
made  to  more  effectively  handle  MCM  prototypes  therefore  reducing  cycle  time  and  costs 
associated  with  these  programs. 
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Design  Framework  -  the  study  of  integration  requirements  and  results  of  integrating  design 
and  release  tools. 


1.2.2.2  MCM  Test 

This  section  describes  the  developed  test  methodology  and  guidelines  for  MCMs  along  with  the 
description  of  the  test  challenges,  implementation  results,  and  related  findings. 

1.2.2.3  C4,  Wirebond,  and  Tab  Interconnect  Integration 

An  MCM-D  test  vehicle  was  built  and  physically  analyzed  that  contained  a  mixture  of  the  three 
types  of  interconnect.  A  summary  of  activities  related  to  reducing  cost  is  also  provided. 

1.2.2.4  Infrastructure 

Throughout  the  contract  significant  effort  was  placed  on  sharing  the  knowledge  gained  in  the 
contract.  Areas  of  substrate  standardization,  computed  aided  design  issues,  module  test,  and 
interconnect  technology  were  supported  throughout  the  contract  period. 

1.2.2.5  Application  Demonstration 

In  support  of  demonstrating  progress  on  a  number  of  contract  objectives,  MCMs  were  fabricated, 
assembled,  and  tested  for  three  customers.  This  section  describes,  the  application  survey,  customer 
selection  overview,  and  the  individual  demonstration  vehicles. 
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2.0  DESIGN  SYSTEM 

This  section  provides  insight  into  the  specific  aspects  of: 

•  Trade-off  tools 

•  MCM  Design  Kits 

•  Multi-entry  foundry  interfaces 

•  Direct  release  of  products  to  the  foundry 

•  Integration  Frameworks 

2.1  Trade-off  tools 

2.1.1  Introduction 

This  subsection  was  created  from  the  full  report  on  trade-off  tools  which  was  submitted  as  a 
contract  deliverable:  “Trade-Off  Tool  Recommendations  Report”,  CLIN  0002AE. 

Trade-off  tools  are  used  to  help  make  early  decisions  about  specific  alternatives  and  their  impact  to 
product  objectives,  even  during  the  product  definition  phase  of  a  program.  For  this  reason,  it  is 
believed  that  a  trade-off  tool  would  be  very  useful  for  reducing  costs,  throughput  time  and 
decreased  time  to  market.  Therefore  a  survey  and  evaluation  of  existing  tools  was  made  in  order  to 
determine  the  degree  to  which  they  could  be  supported  near  term. 

A  set  of  requirements  has  been  established  for  an  MCM  Trade-off  Advisor  and  is  described  below 
along  with  the  results  of  comparing  existing  advisors  against  the  requirements  for  a  range  of 
domains.  The  details  of  this  is  described  by  the  rest  of  this  section. 

2.1.1.1  List  of  Tools 

The  following  tools  were  evaluated  in  detail: 

1 .  Cornell  University's  AUDiT  Trade-off  Tool 

2.  IBM  Corporation's  PEPPER  Trade-offTool 

3 .  MCC's  MSDA  Trade-off  tool 

4.  Stanford  University's  SUSPENS  Trade-offTool 

5 .  Cadence  Corporation's  Thermal  and  Reliability  Advisors 

6.  Cognition's  Manufacturing  Cost  Advisor 

Stanford  University's  SUSPENS  trade-off  tool  is  no  longer  supported  and  is  no  longer  in  use. 
Therefore,  a  report  on  this  tool  is  omitted. 

Interim  reports  were  written  on  all  these  tools  and,  with  the  exception  of  the  SUSPENS  tool,  are 
included  as  an  addendum  to  the  “Trade-OffTool  Recommendations  Report”,  CLIN  0002AE. 

2.1. 1.2  Evaluation  Domains 

Each  of  the  tools  were  evaluated  in  the  following  domains: 

•  User  Interfaces 

•  Interfeces  to  Detailed  Simulation  Tools 
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•  Trade-off  Tool  Performance  and  Accuracy 

•  Cost 

•  Turn  Around  Time  and  Availability 

•  Electrical 

•  Delay 

•  Signal  Integrity 

•  DC  Drop  Analysis 

•  Electromagnetic  Radiation  Compatibility  (EMC) 

•  Thermal  Analysis 

•  Package  /  Physical  Analysis 

•  Package  Size 

•  Partitioning 

•  Routing 

•  Test 

•  Mechanical/Environmental 

•  Reliability 

2.1.1.3  Evaluation  Criteria 

In  evaluating  design  advisors  the  following  criteria  was  used: 

1.  Cost  Savings 

2.  Time  To  Market  Savings 

3.  Critical  Technical  Requirements  and  Benefits 

Note:  Based  on  preliminary  evaluations,  available  information  and  trade-off  tool  offerings  it  was 
decided  to  substitute  Cadence  for  Mentor  Graphics.  Cadence  offers  both  a  thermal  advisor  and  a 
reliability  advisor  that  is  tightly  integrated  with  the  their  layout  and  placement  tool.  As  there  is  a 
strong  interrelationship  between  thermal  characteristics  and  reliability  it  was  important  to  have 
these  two  tools  together  so  that  they  could  be  traded  off  against  each  other.  Mentor  Graphics  does 
not  currently  offer  a  reliability  analysis  tool. 

2.1.2  Trade-Off  Tool  Requirements 

The  MCM  Design  Advisor  Requirements  document  that  is  attached  to  “Trade-Off  Tool 
Recommendations  Report”,  CLIN  0002AE,  details  the  requirements  for  an  MCM  trade-off  tool 
based  on  both  customer  and  tool  developers  feedback.  These  requirements  are  summarized  in 
Figure  2.1-1.  The  requirements  break  down  into  technical  requirements  and  business 
requirements. 

Figure  2.1-2  shows  the  decision  process  for  trade-off  analysis.  The  customer  works  interactively 
with  the  design  advisor  and  generates  a  set  of  customer  requirements  which  are  then  fed  into  the 
design  and  build  phases  of  the  process.  Ideally,  the  tool  generates  estimates  for  cost,  turnaround 
time,  and  performance.  It  can  also  provide  package  alternatives  and  electronic  design  automation 
(EDA)  vendor  options. 

The  trade-off  tools  evaluated  in  this  report  were  measured  against  the  requirements  detailed  in  the 
MCM  Design  Advisor  Requirements  document  attached  to  the  “Trade-Off  Tool  Recommendations 
Report”,  CLIN  0002AE. 
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Figure  2.1-1:  Trade-off  tool  features 
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Figure  2.1-2:  Trade-off  tool  process  _ 
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2.1.3  Evaluation  Domain  Overview 

2.1.3.1  Platforms  And  Operating  Systems 

All  the  tools  evaluated,  with  the  exception  of  SUSPENS,  run  on  one  or  more  of  the  commercial 
workstations.  They  all  use  UNIX  or  AIX  operating  systems.  This  means  that  it  is  straight  forward 
to  port  the  trade-off  tool  to  anyone  of  the  commercial  workstations.  No  trade-off  tool  has  been  run 
on  a  personal  computer.  Whilst,  it  would  not  be  feasible  for  all  the  features  of  a  trade-off  tool  to 
run  on  a  personal  computer,  some  tools  such  as  a  cost  advisor  could  readily  be  ported  to  a  personal 
computer. 

2.1.3.2  User  Interfaces 

In  general  the  trade-off  tools  evaluated  had  good  user  interfeces  with  multiple  windowing 
capabilities.  MCC's  user  interface  has  an  added  attractive  feature  that  incorporates  the  process 
flow  as  part  of  the  user  interface.  This  enables  the  user  to  access  any  part  of  the  process  rapidly. 

2.1.3.3  Interfaces  To  Detailed  Simulation  Tools 

In  general  interfaces  to  other  detailed  simulators  have  not  been  developed.  The  PEPPER  tool  has 
developed  interfaces  to  the  IBM  internal  downstream  simulators  and  can  accept  netlist  input. 
However,  interfeces  to  outside  commercial  EDA  tools  have  not  been  developed.  MCC's  MSDA 
has  links  developed  to  Cadences  VIABLE  reliability  tool  and  to  both  OEA  International's 
Simulator  and  SPICE.  As  an  interim  step  procedural  interfaces  can  be  easily  build  for  linking  to 
EDA  tools.  For  the  long  term,  standard  interfaces  such  as  EDIF  need  to  be  developed. 

2.1.3.4  Component  Libraries 

With  the  exception  of  Cadence's  VIABLE  and  Thermax,  component  libraries  are  a  major 
deficiency  of  the  trade-off  tools  evaluated.  The  PEPPER  tool  has  adequate  libraries  for  IBM 
internal  components.  However,  the  developers  of  the  tool  need  to  address  libraries  for  outside 
commercial  components. 

2.1.3.5  Trade-offTool  Performance  and  Accuracy 

For  a  trade-off  tool  to  meet  customer  requirements  the  turn  around  time  needs  to  be  fast  so  that  a 
large  number  of  iterations  can  be  processed  in  a  short  time.  All  of  the  tools  evaluated  met  this 
requirement.  The  accuracy  of  the  tools  varies  and  is  detailed  in  the  interim  reports.  For  electrical 
analysis  PEPPER  yielded  the  most  accurate  results.  For  thermal  analysis  good  accuracy  is  to  be 
expected  because  of  the  3  dimensional  algorithms  used  to  calculate  thermal  characteristics. 
Cadence's  reliability  tool  is  backed  by  the  MIL-HDBK-217F  handbook.  It  is  difficult  to  assess  the 
accuracy  of  the  MSDA  and  AUDiT  tools  because  they  have  not  been  used  to  develop  products. 

2.1.3.6  Cost 

Three  cost  tools  were  evaluated;  Cognition’s  Cost  and  Manufacturability  Guide,  MCC's  MSDA 
cost  advisor  and  MCC's  High  Level  Test  Economics  Advisor,  (HI-TEA).  Comments  on  these  tools 
are  as  follows: 

1 .  Cognition's  Cost  and  Manufacturing  Guide  provides  a  software  shell  for  capturing  process 
costs.  However,  no  cost  model  exists  for  MCM  manufacturing  and  assembly.  If  a  model 
for  MCM  manufacturing  is  developed  it  will  significantly  improve  the  cost  estimation 
process  in  both  time  and  cost  consistency. 

2.  MCC's  MSDA  cost  advisor  is  specific  to  MCM  module  assembly.  However,  cost  data  is 
hard  coded  currently  and  cannot  be  altered  by  the  user.  MCC  is  planning  to  correct  this 
deficiency  in  the  near  future. 
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3.  MCC's  High  Level  Test  Economics  provides  for  user  cost  inputs.  The  focus  of  this  tool  is 
on  test  costs.  MCC  is  planning  to  combine  this  tool  with  the  MSDA  tool. 

As  manufacturing  costs  are  very  foundry  dependent,  it  is  recommended  that  direct  electronic  links 
be  established  between  the  foundry  and  the  cost  trade-off  tool  so  that  the  database  can  be  updated 
rapidly  and  in  real  time. 

2.1.3.7  Turn  Around  Time  and  Availability 

None  of  the  tools  evaluated  calculates  turn  around  time.  As  turn  around  time  is  very  foundry 
dependent,  it  is  recommended  that  details  of  factory  throughput  and  availability  be  provided  as  a 
lookup  table  and  that  electronic  links  be  established  between  the  foundry  and  the  trade-off  tool  so 
that  the  database  can  be  updated  rapidly  and  in  real  time. 

2.1.3.8  Electrical 
Delay 

The  following  tools  estimate  delay: 

1 .  Cornell  University's  AUDiT  Trade-off  Tool 

2.  IBM  Corporation's  PEPPER  Trade-off  Tool 

3.  MCC's  MSDA  Trade-off  tool 

The  AUDiT  tool  analyses  both  chip  delay  and  module  delay.  MSDA  estimates  package  delay 
only.  The  PEPPER  tool  factors  in  both  chip  and  package  delay.  Because  the  PEPPER  tool  uses  3 
dimensional  analysis  of  parametrics,  coupled  with  a  detailed  simulation  of  net  segments,  this  tool  is 
rated  the  best  for  delay  estimations. 

Signal  Integrity 

Both  Cornell  University's  AUDiT  Trade-off  Tool  and  IBM  Corporation's  PEPPER  Trade-off  Tool 
analyze  for  cross-talk  and  signal  attenuation.  Because  of  the  use  of  3  dimensional  analysis 
techniques  the  PEPPER  tool  is  rated  the  best  for  cross-talk.  MCC's  MSDA  trade-off  tool  analyzes 
signal  attenuation.  However,  again  because  of  the  use  of  3  dimensional  analysis  techniques  the 
PEPPER  tool  is  rated  the  best  for  signal  attenuation  analysis. 

DC  Drop  Analysis 

MCC's  MSDA  trade-off  tool  estimates  inter-planar  DC  drops.  This  is  a  valuable  feature  with 
sufficient  accuracy  for  early  estimations. 

Electromagnetic  Radiation  Compatibility  (EMC) 

None  of  the  trade-off  tools  evaluated  does  EMC  trade-off  analysis.  As  the  frequency  requirements 
increase  EMC  will  become  critically  important.  At  the  1993  Design  Automation  Conference  Racal 
Redac  announced  the  development  of  an  EMC  Advisor. 

2. 1.3.9  Thermal  Analysis 

The  following  trade-off  tools  perform  thermal  analysis. 

1 .  Cornell  University's  AUDiT  Trade-off  Tool 

2.  MCC's  MSDA  Trade-off  tool 

3.  Cadence  Corporation's  Thermax  Advisor 
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The  use  of  Cornell  University's  AUDiT  Trade-off  tool  is  too  limited  to  be  useful.  (It  should  be 
noted  that  Cornell  has  recently  announced  an  upgrade  of  the  thermal  tool).  MCC's  MSDA  thermal 
analysis  tool  is  comprehensive.  However,  Cadence  Coiporation's  Thermax  Advisor  has  the 
advantage  that  it  is  based  on  3  dimensional  thermal  analysis  and  has  an  attractive  graphics  output. 

2.1.3.10  Package  /  Physical  Analysis 
Package  Size 

The  following  tools  perform  package  trade-off  analysis 

1 .  Cornell  University's  AUDiT  Trade-off  Tool 

2.  IBM  Corporation's  PEPPER  Trade-off  Tool 

3.  MCC's  MSDA  Trade-off  tool 


Each  of  these  tools  use  a  similar  theoretical  approach  for  estimation  of  package  sizes.  There  is  a 
reasonable  correlation  between  theory  and  experimental  results  for  early  estimations  of  package 
sizes. 

Partitioning 

The  following  tools  perform  partitioning 

1 .  Cornell  University's  AUDiT  Trade-off  Tool 

2.  IBM  Corporation's  PEPPER  Trade-off  Tool 

3 .  MCC's  MSDA  Trade-off  tool 

Both  MSDA  and  PEPPER  have  interactive  floor  planning  capability.  The  PEPPER  tool  features 
congestion  driven  floor  planning.  Neither  the  PEPPER  or  MSDA  tools  have  chip  partitioning 
capability.  The  AUDiT  tool  has  both  chip  and  module  level  partitioning  capabilities. 

Routing 

The  following  tools  have  routing  capabilities 

1.  IBM  Corporation's  PEPPER  Trade-off  Tool 

2.  MCC's  MSDA  Trade-off  tool 


Both  tools  have  acceptable  routing  performance  capabilities. 

2.1.3.11  Test 

MCC's  High  Level  Test  Economics  Advisor  estimates  test  costs  based  on  user  inputs  for  both  costs 
and  test  coverage.  However,  the  tool  does  not  breakdown  costs  of  different  test  strategies  such  as 
Level  Sensitive  Scan  Designs,  (LSSD)  and  Built  In  Self  Test,  (BIST).  These  cost  figures  should 
be  generated  by  the  MCM  foundry. 

2.1.3.12  Mechanical/Environmental 

None  of  the  tools  evaluated  does  trade-off  analysis  for  mechanical  performance. 
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2.1.3.13  Reliability 

Cadence  Corporation's  VIABLE  is  the  only  tool  evaluated  that  performs  reliability  analysis.  The 
tool  uses  MIL-HDBK-2 1 7F  handbook  as  die  main  source  of  component  reliability.  No  provisions 
are  made  in  the  tool  for  the  contributions  of  die  attach  methods  to  reliability. 


2.1.4  Tool  Evaluation  Summary 

The  table  below  summarized  the  evaluation  results. 
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EDA  tools. 

Commercial  level 

System 

Acceptable 

databases  need  to  be 

Partition 

established. 

Thermal  tool  needs  to 

Delay 

Acceptable 

be  enhanced  to  model 
typical  thermal 

Signal 

Integrity 

Acceptable 

conditions. 

IBM  Pepper 

Package 

IBM  Tools 

IBM  Only 

Best  of  Breed 

Good  performance. 
Interfaces  need  to  be 

Routing  & 

Best  of  Breed 

developed  to 

Congestion 

commercial  EDA 
tools. 

Floor-Planning 

Good 

Commercial 
databases  need  to  be 

Delay 

Best  of  Breed 

established. 

Signal 

Integrity 

Best  of  Breed 

Cognition 

Manufacturing 

ASCII  File 

MCM 

Not  Acceptable  at 

Good  user  interface. 

CMG 

Costs 

Transfer 

Cost 

this  time 

Fast  cost  analysis. 

Models 

Standard  interfaces 

Needed 

need  to  be  developed 
to  mechanical  design 
tools.  Tool  needs 
graphical  capabilities. 
Cost  models  need  to 

be  developed  for 

MCM  processes 

2-7 


Trade-Off 

Tool 

Trade-off 

Function 

Interface 
to  other 
EDA  Tools 

Extent  of 

Libraries, 

Databases 

Performance 

Rating 

Comments 

MCCMSDA 

Package  Size 

Module  & 

System 

Partitions 

Thermal 

No 

No 

No 

Limited 

Acceptable 

Acceptable 

Acceptable 

Most  comprehensive 
offering  of  trade-off 
tools. 

Good  user  interfaces. 
Assembly  cost  tool 
needs  major  rework. 
Libraries  are  limited. 

Routing 

No 

Acceptable 

Delay 

Linked  to 
OEA& 

Spice 

Simulators 

Acceptable 

Signal 

Attenuation 

No 

Acceptable 

E 

No 

Best  of  Breed 

Reliability 

Linked  to 
Cadence’s 
Viable  Tool 

See  Below 

Assembly  Cost 

Test  Costs 

No 

No 

Not  Acceptable 

Acceptable 

Cadence 

Thermax 

Viable 

(Reliability) 

Linked  to 
Allegro 

Linked  to 
Allegro 

Extensive 
but  not  for 
MCMs 

Extensive 
but  not  for 
MCMs 

Best  of  Breed 

Best  of  Breed 

Database  with 
thermal 
characteristics 
needed  for  MCM 
components 
standard.  Interfaces 
to  other  EDA  tools 
required. 

Database  with  MIT 
data  required  for 

MCM  parts . 

Standard  interface  to 
EDA  tools  required. 
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2.1.5  Tool  Effectiveness  Results 


As  most  of  the  trade-off  tools  that  were  evaluated  have  not  been  used  in  a  production  environment 
it  was  difficult  to  make  an  assessment  of  the  benefits  of  these  tools.  However,  the  following  can  be 
concluded  from  customer  feedback  and  an  assessment  of  design  advisor  capabilities: 

1 .  PEPPER  (IBM)  This  tool  is  unique  among  the  trade-off  tools,  evaluated  because  it  has 
been  used  in  the  development  of  a  significant  number  of  key  IBM  products.  The  feedback 
from  the  users  of  this  tool  is  very  positive.  The  following  are  the  benefits  that  have  been 
identified  for  this  tool: 

a)  The  run  times  are  fast,  approximately  3  minutes,  permitting  a  large  number  of 
iterations  in  a  short  time.  A  typical  number  of  iterations  would  be  approximately  50. 
If  the  PEPPER  tool  did  not  exist  it  is  estimated  that  an  iteration  would  take  about  3 
days  and  quality  of  the  analysis  would  be  degraded  significantly.  This  would  add 
about  5  months  to  the  cycle  time  of  the  product.  As  this  would  be  prohibitive,  the 
designer  would  end  up  doing  fewer  iterations  with  a  resultant  degradation  on  quality 
and  a  decrease  in  the  likelihood  of  first  pass  success. 

b)  Users  of  the  PEPPER  tool  reported  that  the  tool  helped  them  to  quickly  eliminate 
options  that  would  not  have  worked.  Furthermore,  they  regarded  the  tool  as  a  major 
factor  in  achieving  first  pass  success. 

c)  Because  PEPPER  has  been  used  in  a  production  environment  it  is  possible  to  check 
the  accuracy  of  the  tool.  Actual  results  have  been  reported  to  be  within  10%  of 
prediction,  which  for  an  early  analysis  tool  is  very  acceptable. 


2.  Thermax  (CADENCE)  As  component  temperature  is  a  major  concern  in  a  large  number  of 
applications,  Thermax  fills  a  critical  technical  requirement.  The  feedback  on  this  tool  is 
positive.  The  correlation  between  predicted  case  temperatures  and  actual  measured 
temperature  has  been  reported  to  be  within  4  degrees  Celsius.  This  is  excellent. 

3.  Cost  and  Manufacturing  Guide  (COGNITION  CORP.)  Major  cost  savings  and  time 
savings  have  been  reported  for  the  use  of  this  tool. 


The  following  tools  have  not  been  used  for  a  manufactured  application: 

1 .  Cornell  University's  AUDiT  Trade-off  Tool 

2.  MCC'sMSDA  Trade-off  tool 


Therefore,  their  benefits  cannot  be  accurately  assessed  at  this  time.  From  the  data  reported  above 
it  can  be  expected  that  major  savings  in  time  and  costs  can  be  achieved  by  the  use  of  design 
advisors.  In  addition,  the  chances  of  first  pass  success  are  significantly  improved. 


2.1.6  Conclusions 

Investigations  were  completed  and  reports  have  been  submitted  to  satisfy  contract  requirements. 


2-9 


2.1.6.1  Principle  Recommendation 

At  this  time  MCC  is  the  closest  to  a  total  MCM  trade-off  advisor.  However,  there  are  some  major 
shortcomings  in  capabilities.  The  following  is  a  list  of  these  deficiencies: 

1 .  The  most  notable  is  the  lack  of  comprehensive  component  libraries.  It  is  recommended 
that  MCC  form  a  partnership  with  a  major  EDA  vendor  who  will  have  the  resources  to 
build  up  the  component  libraries. 

2.  The  MCC  tools  need  to  be  ported  to  the  IBM  RISC  and  HP  workstations  for  universal 
acceptance  of  MCC's  trade-off  tools.  In  addition,  the  MCC  software  needs  to  be  ported  to 
personal  computers  for  specialized  tasks  such  as  cost  analysis. 

3.  The  links  to  other  EDA  tools  are  limited.  On  an  interim  basis  procedural  interfaces  will  be 
a  temporary  solution.  For  the  longer  term,  standard  interfaces  will  be  required. 

4.  MCC's  Assembly  Cost  Analysis  tool  needs  major  work.  Process  cost  variables  need  to  be 
made  user  definable.  Ideally,  cost  figures  should  originate  from  the  MCM  foundries  and 
be  updated  electronically.  Graphical  output  capability  needs  to  be  added. 

5.  Chip  partitioning  capability  needs  to  be  added  to  the  tool. 


A  major  advantage  of  the  MSDA  tools  is  that  all  the  design  advisors  have  been  integrated  under  the 
same  operating  system.  This  results  in  a  common  look  and  feel  in  the  user  interface.  MCC's 
strategy  for  linking  to  the  Cadence  Viable  tool  is  a  good  one.  It  still  provides  the  concept  of  "one 
stop  shopping"  without  having  to  develop  a  new  tool. 

2.1.6.2  Point  Solution  Tools 

PEPPER  is  an  excellent  trade-off  tool.  IBM  has  indicated  an  interest  in  offering  a  broad  based 
trade-off  tool  capability.  PEPPER  would  be  an  excellent  foundation  tool  for  this  purpose.  For 
general  acceptance  it  will  need  to  be  ported  to  the  SUN,  HP  and  DEC  workstations.  Also,  the 
library  capabilities  will  need  to  be  extended. 

The  AUDiT  tool  has  a  number  of  features  that  should  be  incorporated,  if  possible,  in  an  integrated 
trade-off  tool.  These  include  (a)  chip,  module  and  system  partitioning  and  (b)  statistical 
optimization. 

An  offering  for  a  mechanical  trade-off  advisor  was  not  identified.  This  requirement  needs  to  be 
addressed  in  the  future.  The  need  for  an  EMC  advisor  was  identified.  Racal  Redac  has  announced 
an  EMC  trade-off  tool.  This  tool  needs  to  be  evaluated. 

2. 1.6.3  Future  Work 

It  is  clear  that  major  work  has  to  be  done  before  a  fully  integrated  and  a  fully  tested  trade-off  tool 
is  in  place.  The  focus  of  this  work  should  address  the  following  issues: 

1 .  Establish  a  "Best  of  Breed"  tool  set  of  trade-off  advisors  that  function  under  a  single 
operating  environment  that  is  ported  to  the  common  workstations  and  in  certain  special 
applications  ported  to  personal  computers. 

2.  Develop  standard  interfaces  between  the  trade-off  tool  and  the  major  EDA  vendors 
software. 

3.  It  is  recommended  that  a  test  vehicle  be  identified  and  used  to  evaluate  the  following: 
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a)  A  "Best  of  Breed"  set  of  design  advisors 

b)  The  performance  and  accuracy  of  an  integrated  trade-off  tool 

c)  A  comprehensive  component  library  system 

d)  Standard  interfaces  to  detailed  EDA  design  tools 

There  is  no  current  tool  that  sufficiently  addresses  the  needs  of  the  industry,  either  because  of  lack 
of  supporting  data/libraries  or  due  to  the  limited  capabilities.  Follow  on  activity  will  require 
funding  to  develop  solutions  that  are  widely  accepted. 
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2.2  Design  Kits 

Design  kits  have  been  developed  for  IBM’s  MCM-D  technology  for  the  Cadence  and  Mentor 
Graphics  tool  sets.  These  kits  were  developed  through  a  prototyping  process  where  test  case 
designs  were  mapped  into  the  design  systems.  The  kits  include  hard-copy  documentation  and  a 
tape,  or  other  magnetic  media,  which  contains  design  tool  specific  information,  soft-copy 
documentation,  and  custom  software  to  initialize  a  design  environment. 

In  the  process  of  creating  these  kits  a  number  of  documents  were  created.  These  documents  are: 

“ASEM  Design  System  Requirements  Report  (Design  Tools  supported  by  MCM-D  Design 
Kits)”,  CLIN  0002AD,  which  defines  tool  sets  that  were  considered  in  putting  the  design 
kits  together  as  well  as  defines  the  components  of  a  general  design  system. 

“ASEM  Design  Kit  Specification”,  CLIN  0002AF,  which  generalizes  design  kit  entities  and 
formats  that  provides  a  basis  for  consistency  among  many  kits. 

“MCM-D  Design  Kit  (1  of  2),  Using  the  Cadence  Allegro  Design  System”  CLIN  0002AC,  the 
design  kit  that  describes  MCM-D  technology  design  using  Cadence  tools.[l] 

“MCM-D  Design  Kit  (2  of  2),  Using  the  Mentor  Graphics  MCM  Station  Design  System” 
CLIN  0002AC,  the  design  kit  that  describes  MCM-D  technology  design  using  Mentor 
Graphics  tools. [2] 


The  purpose  of  Design  kits  is  to  facilitate  quicker,  cheaper,  error  free  designs.  They  do  this  first, 
through  a  process  of  describing  technology  requirements,  capabilities,  and  standard  offerings. 
Secondly,  the  kits  establish,  within  the  design  system  capabilities,  a  set  of  tool  parameters  that 
maximizes  the  possibility  of  conformance  to  technology  preferences.  This  does  not  imply  that 
either  design  tool  set  is  currently  sufficient  within  itself  to  insure  technology  conformance,  but  that 
through  a  combination  of  tool  capabilities  and  methodology  control  conformance  is  possible. 

To  say  this  another  way,  design  kits  provide  both  information  to  guide  design  system  users  and 
data  that  controls  or  is  used  by  the  tools.  The  tool  data  consists  of: 

•  Control  parameters  to  insure  design  rules  are  met 

•  Partially  complete  design  elements 

•  Process  automation  routines. 

Design  kits  are  aimed  at  helping  users  achieve  solutions  with  reduced  cycle  time  and-or  reduced 
non-recurring  engineering  costs. 

The  organization  of  this  section  is  as  follows: 

•  Design  System  Requirements  -  describes  the  design  tool  sets  for  which  the  kits  were 
developed 

•  Design  Kit  Specification  -  outlines  the  generalized  information  that  is  found  in  design  kits 

•  Cadence  MCM-D  Design  Kit  -  describes  specifics  of  the  Cadence  Kit  and  use  experience 

•  Mentor  Graphics  MCM-D  Design  Kit  -  describes  specifics  of  the  Mentor  Graphics  kit  and 
use  experience 

•  Conclusion  -  a  summary  of  conclusions  that  result  from  the  design  kit  development  efforts 
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2.2.1  Design  System  Requirements 

Design  systems  must  provide  certain  capabilities  to  support  Multichip  Module  (MCM)  design.  A 
detailed  description  of  these  requirements  is  defined  in  die  contract  deliverable  “ASEM  Design 
System  Requirements  Report  (Design  Tools  supported  by  MCM-D  Design  Kits)”,  CLIN  0002AD. 
This  section  will  not  go  into  the  full  detail  but  will  touch  on  the  highlights  of  that  report.  It  will 
briefly  describe  a  general  design  system,  then  specifically  define  the  Cadence  and  Mentor  Graphics 
design  tools  that  were  selected  for  support  in  their  respective  design  kits. 

2.2.1. 1  General  Design  System 

A  general  design  system  has  the  capability  to  support  specification  development,  logic  design, 
physical  design,  and  manufacturing  release.  As  shown  in  Figure  2.2-1,  adapted  from  the  Design 
System  Architecture  described  in  the  referenced  SWAP  final  report  [3],  design  system  components 
generally  can  be  encompassed  in  a  framework  that  works  out  of  a  database  structure. 


Adapted  from  Design  System  Arch,  from  referenced  SWAP  Report  (figure  8) 


Figure  2.2-1.  MCM  Design  System 


Typically,  two  levels  of  tools  are  used  in  the  design  process,  detailed  design  tools  and  trade-off 
tools.  Detailed  design  tools  are  used  for  full  implementation  or  evaluation  of  specific  objectives. 
Trade-off  tools  assist  at  specific  design  levels  by  helping  to  clarify  benefits  and  drawbacks  of 
potential  alternatives.  These  tools  do  not  require  full  detailed  design  at  the  current  design  level  in 
order  to  provide  guidance  for  decisions  that  need  to  occur.  Trade-off  tools  provide  quick  turn 
around  time  for  responses  to  various  design  alternative  questions. 

2.2.1. 1.1  Specification  Level  Tools 

Specification  tools  capture  specifications  related  to  function,  cost,  performance,  form  factors, 
reliability  objectives,  and  other  product  requirements.  Specification  definition  is  accomplished 
conceptually  with  the  help  of  trade-off  tools  or  advisor  type  tools.  Actual  specifications  currently 
are  not  captured  or  enforced  in  a  computer  sensible  manner  for  use  by  design  tools. 
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This  is  demonstrated  by  the  fact  that  specification  information,  outside  of  logic  specification,  is 
often  conveyed  by  ASCII  text,  postscript,  or  hard-copy  forms. 

2.2.1.1.2  Logic  Design  Level  Tools 

The  logic  design  level  tools  encompass  the  following  functions: 

•  Design  capture  to  establish  the  expression  of  the  detailed  logic  as  a  schematic,  including  the 
generation  of  required  schematic  symbols  used  for  graphically  representing  circuits  and  chips 
on  the  schematic.  The  interconnections  between  chip  boundaries  are  defined  in  netlists  within 
the  capture  tool.  Performance  constraints  are  also  captured  for  individual  nets  for  transfer  to 
the  physical  design  tools. 

•  Simulation  to  verify  the  function  of  the  logic,  including  the  generation  of  test  cases  and 
simulation  models  used  in  the  simulation. 

•  Timing  to  verify  that  electrical  performance  of  the  logic  meets  timing  requirements.  This 
includes  the  expression  of  physical  constraints  which  must  be  followed  during  layout  of  the 
logic  in  order  to  stay  within  the  performance  requirements. 

•  Fault  analysis  to  allow  fault  simulation  that  quantifies  the  coverage  of  design  verification  tests 
and  manufacturing  tests. 

2.2.1.1.3  Physical  Design  Level  Tools 

Physical  design  includes  layout  and  analysis  tools  that  verify  functional  objectives  are  achieved 
within  a  specific  implementation.  This  includes: 

•  Placement,  routing  and  design  rule  checking  insure  logical  to  physical  requirements  are  met 

•  Thermal  analysis  insures  that  placement  and  cooling  technology  can  support  semiconductor 
operating  requirements  and  data  is  passed  to  reliability  tools  to  insure  those  objectives  are  met 

•  Electrical  analysis  in  conjunction  with  electrical  design  rules  insure  that  signal  performance 
objectives  are  met  and  back  annotation  of  actual  route  delay  information  is  available  for  logic 
level  timing  tools 

•  Manufacturability  of  the  design. 

2.2.1.1.4  Manufacturing  Release  Tools 

Manufacturing  release  tools  are  ones  that  create  information  in  the  proper  formats  to  support 
documentation,  tooling,  and  release  needs  of  the  manufacturing  process.  These  are  foundry  specific 
files  that  are  needed  for  manufacturing  and  are  generally  created  by  the  foundry. 

2.2.1. 1.5  Further  Information 

Additional  design  system  description  can  be  found  in  the  ‘Silicon  Wafer  Advanced  Packaging 
(SWAP)  Final  Report’.  ARPA  order  number  7549/1  under  contract  MDA972-90-C-0064.[3] 
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2.2.1.2  Cadence  Tool  Set 

Figure  2.2-2  shows  the  Cadence  tool  relationships.  Tools  in  dashed  boxes  are  supported  primarily 
through  text  assistance  rather  than  control  or  data  initialization.  The  software  version  is  intended  to 
be  the  latest  version  available  as  of  June  1993  unless  otherwise  noted. 

2.2.1.2.1  Physical  Design  Level  Tool  List 
The  tools  defined  at  this  level  are: 

Allegro  7.0 

Design  for  Thermal  Integrity  /Thermax/ 

Design  for  Signal  Integrity  /SigNoise/ 

Design  for  Reliability  /Viable/ 

Design  for  Assembly 

SPICE 

DRACULA 


2.2.1.2.2  Logic  Design  Level  Tool  List 
The  tools  defined  at  this  level  are: 

Concept 

Composer 

LeapFrog 

Verilog-XL 

Veritime 

Verifault-XL 

EDIF  Interface 

ValidPACKAGER 

2.2.1.2.3  Specification  Level  Tool  List 

Specific  tools  are  not  available  which  define  specifications  such  as  cost,  reliability,  or  performance 
objectives. 

Some  of  the  tools  listed  in  the  physical  design  section  can  be  worked  in  a  trade-off  tool  fashion. 

The  results  of  such  a  comparative  analysis  can  assist  in  directing  users  to  appropriate  solutions 
leading  to  specifications.  Trade-off  capabilities  of  the  tools  are  described  in  die  appropriate 
appendix  of  reference  [14]. 
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Mfg  Output 


LeapFrog 


VHDL  Simulation 


EDIF  Interface 


Data  Transfer 


Design  Specifications 


Cadence  Physical  Design  Tools 


Therm  ax 
Thermal  Analysis 


Reliability  Analysis 

SigNoise 
Signal  Integrity 
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Electrical  Analysis 

DF/Assembly 
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PostDesignChecks 


(TO)  Trade  off  support 


Release  to  Foundry 


Figure  2.2-2.  Cadence  Tool  Set 
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2.2.1.3  Mentor  Graphics  Tool  Set 

Figure  2.2-3  shows  the  Mentor  Graphics  tool  relationships.  Tools  in  dashed  boxes  are  supported 
primarily  through  text  assistance  rather  than  control  or  data  initialization.  The  software  version  is 
intended  to  be  the  latest  version  available  as  of  June  1993  unless  otherwise  noted. 

2.2.1.3.1  Physical  Design  Level  Tool  List 
The  tools  defined  at  this  level  are: 

LIBRARIAN 

LAYOUT  500 

AutoTherm 

SMARTROUTERs 

Quad  Design  XTK(XFX/XNS)  PDQ 

FabLink 

CheckMate 

2.2.1.3.2  Logic  Design  Level  Tool  List 
The  tools  defined  at  this  level  are: 

Design  Architect 

PACKAGE 

EDIF  Interface 

SimView 

System  1076 

QuickSim  II 

QuickPath 

QuickFault  II 

QuickGrade 

FlexTest 

FastScan 

QuickCheck 

2.2.1.3.3  Specification  Level  Tool  List 

Specific  tools  are  not  available  which  define  specifications  such  as  cost,  reliability,  or  performance 
objectives. 

Some  of  the  tools  listed  in  the  physical  design  section  can  be  worked  in  a  trade-off  tool  fashion. 
The  results  of  such  a  comparative  analysis  can  assist  in  directing  users  to  appropriate  solutions 
leading  to  specifications.  Trade-off  capabilities  of  the  tools  are  described  in  die  appropriate 
appendix  of  reference  [14]. 
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Design  Specifications 


Physical  Design 


Figure  3.  Mentor  Graphics  Tool  Set 
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2.2.2  MCM-D  Design  Kit  Specification 

The  latest  version  of  the  complete  design  kit  specification  entitled  “ASEM  Design  Kit 
Specification”  CLIN  0002AF,  is  dated  June  3,  1994.  This  section  will  cover  the  general  ideas  of 
the  specification  and  how  it  can  be  used  in  generating  and  reviewing  to  design  kits.  While  the 
“ASEM  Design  Kit  Specification”  describes  the  many  types  of  support  possible,  within  the  tool 
sets  described,  a  foundry  may  choose  not  to  support  all  these  types.  However,  even  with  only 
partial  support,  a  design  kit  can  be  useful  since  it  clarifies  aspects  of  design  within  a  supported  tool 
set. 

2.2.2.1  Introduction 

In  compiling  design  kits  for  the  Mentor  Graphics  and  Cadence  design  tools,  the  required  kit 
information  was  determined  to  be  equivalent  in  nature  but  needed  to  be  fitted  uniquely  to  the  tools 
and  algorithms  incorporated  in  the  tools  (e.g.  routing  parameters  for  routers  that  enforce  design 
rule  requirements).  The  specification,  therefore,  tries  to  describe  the  information  content  of  a 
design  kit. 

To  create  a  design  kit,  a  foundry  has  to  map  the  technology  information  described  in  this 
specification  into  the  specific  CAD  tool  (e.g.  Mentor  Graphics,  Cadence)  parameters  and  formats. 
Ideally,  CAD  tool  formats  will  migrate  to  industry-standard  formats  like  the  DIE  information 
format  [4]  to  minimize  foundry  resources  spent  supporting  the  tools. 

In  addition  to  base  CAD  tool  functionality,  CAD  tools  which  interact  with  extension  languages 
allow  additional  new  functions  (programs)  to  be  developed  to  support  specific  foundry 
requirements.  This  capability  provides  for  a  wide  range  of  design  kit  extensions  for  such  design 
tools.  Examples  of  this  type  of  customized  software  is  included  in  this  document. 

There  are  three  types  of  data  described  in  a  design  kit.  The  three  general  types  are: 

Documentation  (e.g.  The  design  process,  tutorials,  selections  from  the  foundry's  "customer- 
foundry  interface  specification"  and  "user's  guide".) 

CAD  rules,  models,  libraries,  design  tool  parameter  settings  (e.g.  Technology  specific 
information) 

Specialized  software  (e.g.  Special  technology  selection  software,  checking  software) 


The  following  section  is  included  to  aid  in  describing  the  relationship  of  design  kit  information  to  a 
design  process. 

2.2.2.1.1  MCM  Design  Flow  and  Tool  Oriented  Kit  Information 

This  section  gives  an  overview  of  how  the  tool  specific  information  supports  the  design  process. 
Figure  2.2-4  'MCM  Design  Flow'  illustrates  the  customer-foundry  process  used  to  design  and 
deliver  customer  requirements  for  an  MCM.  This  flow  will  be  used  to  illustrate  the  relationship  of 
the  design  kit  information  to  the  design  process. 
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MCM  Design  Flow 


A  =  Techology  data  needed  for  trade-off  analysis 
B1  =  Rules  and  models  for  logic  design  (netlist  creation) 

B2  =  Rules  and  models  for  engineering  analysis  at  the  logical  level 
Cl  =  Rules  and  models  for  physical  design  (placement  and  routing) 
C2  =  Rules  and  models  for  engineering  analysis  at  the  physical  level 
D  =  Technology  rules  needed  for  "final"  manufacturing  rules  checking 

Figure  4.  MCM  Design  Flow _ 
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2.2.2.1.2  Design  Kit  Information  Element  Definitions 

Referencing  Figure  2.2-4,  Table  2.2-1  describes  technology  information  that  is  needed  to  support 
the  design  process.  Each  element  is  supported  with  documentation,  CAD  rules  etc.,  and 
specialized  software. 


ITEM 

DESIGN  KIT  INFORMATION  ELEMENTS 

A 

Technology  data  needed  for  trade-off  analysis 

Bl 

Rules  and  models  for  logic  design  (netlist  creation) 

B2 

Rules  and  models  for  engineering  analysis  at  the  logical  level 

Cl 

Rules  and  models  for  physical  design  (placement  and  routing) 

C2 

Rules  and  models  for  engineering  analysis  at  the  physical  level 

D 

Technology  rules  needed  for  "final"  manufacturing  mles 
checking(Described  in  a  Design  Ground  Rules  document) 

Table  2.2- 


.  Design  Kit  Information  Element  Definitions 


Each  major  process,  Trade-off  Analysis,  Logic  Design,  and  Physical  Design,  has  both  a  design 
component  and  an  analysis  component  as  illustrated  by  the  break  out  of  the  design  and  analysis 
activity  in  the  physical  design  section.  In  Figure  2.2-4;  Bl,  B2,  Cl,  and  C2  are  broken  out  to 
illustrate  this  point. 

2.2.2.1.3  Design  Entry  Definitions 

All  levels  of  entry  into  the  foundry  pass  through  the  Request  for  Quotation  (RFQ)  and  Trade-off 
analysis  phase.  This  allows: 

•  Technical  assumptions  to  be  established  in  a  conceptual  design  document 

•  Business  assumptions  to  be  defined  such  as  schedules  and  responsibilities 

•  A  quote  to  be  returned  to  the  customer  for  their  decision  and  approval. 

Table  2.2-2  describes  design  entry  definitions  relative  to  Figure  2.2-4. 

The  documentation  needed  to  support  these  levels  is  described  in  the  following  section. 

2.2.2.2  Documentation 

The  documentation  that  accompanies  a  design  kit  is  standardized  so  that  users  can  quickly  and 
consistently  find  kit  information  regardless  of  the  tool  set  or  the  technology  the  kit  was  created  to 
support.  To  accomplish  the  standardization  a  common  documentation  outline  was  defined  and  is 
described  below.  Also  described  are  documents  that  the  foundry  can  provide  that  contribute  to  the 
content  of  the  design  kit  documentation.  These  are  described  after  the  Kit  Documentation  Outline. 


2.2.2.2.1  Design  Kit  Documentation  Outline. 


The  Design  Kit  documentation  describes  information  that  comes  from  a  variety  of  foundry 
documents.  Some  of  the  information  can  come  from  a  “Foundry  User's  Guide”.  Kit 
documentation  includes  design  tool  specific  information  about  the  design  process,  CAD  sensible 
design  data,  and  custom  software  developed  to  support  the  design  process  within  the  particular  tool 
set  for  the  technology  defined  in  “Design  Ground  Rules”.  It  also  picks  from  the  “IBM  MCM 
Foundry  Interface  Specification”^]  the  applicable  data  paths  that  are  available  for  the  supported 
toolsets.  The  information  is  organized  as  shown  in  Table  2.2-3. 


2-22 


ENTRY  I  DESCRIPTION 


S  Specification  level  design  entry 

At  the  specification  level  design  entry,  there  is  a  conceptual  design  in  a  particular  MCM 
technology,  a  customer  quotation,  and  the  agreed  to  assumptions  between  the  foundry 
and  the  customer  which  might  include  a  test  plan,  a  design  schedule,  and  a  list  of 
responsibilities. 


Using  the  flow  in  Figure  2.2-4,  a  customer  (alone  or  with  foundry  help)  has  used 
information  from  'A'  in  order  to  develop  requirements  and  supplies  the  foundry 
information  as  illustrated  with  the  circled  numbers  1  and  2. 


Logical  level  design  entry 

At  the  logic  design  level,  the  MCM  customer  has  performed  requirements  analysis, 
schematic  capture,  and  simulation  in  their  MCM  design  environment.  The  customer 
supplies  the  MCM  logic  design  as  a  netlist  to  the  MCM  foundry,  along  with  acceptance 
tests  and  the  information  required  at  the  specification  level  design  entry,  i.e.,  the 
conceptual  design,  the  customer  quotation,  and  the  agreed  to  assumptions. 

Using  the  flow  in  Figure  2.2-4,  a  customer  has  used  information  from  'A',  'Bl',  and  'B2' 
in  order  to  develop  the  design  and  requirements,  and  supplies  the  foundry  information  as 
illustrated  with  the  circled  numbers  1,  2,  and  3. 


Physical  level  design  entry 

At  the  completed  physical  design  level,  the  MCM  customer  has  performed 
requirements  analysis,  schematic  capture,  simulation,  physical  design,  and  engineering 
evaluation  in  their  MCM  design  environment.  The  customer  supplies  the  MCM 
physical  design,  engineering  evaluation  reports,  and  the  information  described  under 
logical  level  design  entry. 

Using  the  flow  in  Figure  2.2-4,  a  customer  has  used  information  from  'A',  'Bl',  'B2', 
'Cl',  and  'C2'  in  order  to  develop  the  design  and  requirements,  and  supplies  the  foundry 
information  as  illustrated  with  the  circled  numbers  1, 2,  3, 4,  and  5. 


Table  2.2-2.  Design  Entry  Definitions 
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Table  2.2-3.  Design  Kit  Documentation  Outline _ 

Design  Kit  Documentation  Outline 

1.0  Overview. 

1 . 1  Sections  of  interest  (based  on  customer  selections) 

1.2  User  guide  section  descriptions 
2.0  MCM  Technology  Description 

2.1  Substrates 

2.2  MCM  to  Card  interconnect  options 

2.3  Component  attach 

2.4  Module  description 

2.5  Standard  module  offerings 

2.6  Quality  and  reliability 
3.0  MCM  Foundry  Services 
4.0  Other  Services 

5.0  Design  process  overview 

5 . 1  Description  of  design  tools 

5.2  Description  of  tool  specific  process  flows 

5.3  Description  of  data  required  for  tools 
6.0  Conceptual  design 

6. 1  Detailed  design  and  analysis  process 
(including  system  concerns) 

6.1.1  Description  of  design  tools 

6.1.2  Description  of  tool  specific  process  flows 

6. 1 .3  Design  kit  description 

1.  Design  kit  usage 

2.  Design  kit  installation  procedure 

6.2  Tutorial 

6.2.1  Sample  designs 

6.2.2  Sample  analysis 

6.3  Customer-foundry  interface  specifications 

6.3.1  Customer  to  foundry 

1.  Conceptual  design-customer  quotation 

2.  Customer  order-specification 

3.  Reports 

6.3.2  Foundry  to  customer 

1.  Design  guidelines 

2.  Reports 
7.0  Logic  design 

7. 1  Detailed  design  and  analysis  process 

7.1.1  Description  of  design  tools 

7.1.2  Description  of  tool  specific  process  flows 

7.1.3  Design  kit  description 

1.  Design  kit  usage 

2.  Design  kit  installation  procedure 

7.2  Tutorial 

7.2.1  Sample  designs 

7.2.2  Sample  analysis 

_ 7.3  Customer-foundry  interface  specifications _ 
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7.3.1  Customer  to  foundry 

1.  Conceptual  design-customer  quotation 

2.  Customer  order-specification 

3.  Netlist-component  information 

4.  Reports 

7.3.2  Foundry  to  customer 

1.  Design  rules 

2.  Reports 
8.0  Physical  design 

8.1  Detailed  design  and  analysis  process 

8.1.1  Description  of  design  tools 

8.1.2  Description  of  tool  specific  process  flows 

8.1.3  Design  kit  description 

1.  Design  kit  usage 

2.  Design  kit  installation  procedure 

8.2  Tutorial 

8.2.1  Sample  designs 

8.2.2  Sample  analysis 

8.3  Customer-foundry  interface  specifications 

8.3.1  Customer  to  foundry 

1.  Conceptual  design-customer  quotation 

2.  Customer  order-specification 

3.  Netlist-component  information 

4.  MCM  substrate  artwork 

5.  Reports 

8.3.2  Foundry  to  customer 

1.  Design  rules 

2.  Back  annotation  data 

_ 3.  Reports _ 

Table  2.2-3  Design  Kit  Documentation  Outline 

2.2.2.2.2  Design  Kit  Document  Relationships 

Outline  sections  1.0  through  4.0  are  generic.  These  sections  could  reference  a  separate  document 
such  as  a  Foundry  Users  Guide.  Outline  sections  5.0  through  8.0  are  specific  to  tool  sets  and  are 
customized  according  to  the  Design  Ground  rules  requirements.  The  foundry  interface  information 
for  these  sections  (sub-item  X.3  of  these  sections)  are  selected  from  the  sections  of  the  “Foundry 
Interface  Specification”  that  best  applied  to  the  foundry  and  customer  objectives.  The  Design 
Rules  sections  are  determined  from  a  “Design  Ground  Rules”  document.  These  sections  could 
reference  a  separate  document. 

Foundry  User’s  Guide 

A  “Foundry  User's  Guide”  describes  the  technology  and  service  offerings  and  business  processes 
required  to  interact  with  a  customer.  The  guide  also  contains  generic  design  process  information 
and  the  range  of  ways  to  interact  with  the  foundry  (from  the  “Foundry  Interface  Specification”^]). 

The  “Foundry  User's  Guide”  could  be  the  source  of  all  globally  described  information.  Outline 
sections  5.0  through  8.0,  which  are  specifically  defined  in  design  kit  documentation,  would  be 
substituted  with  a  general  superset  of  applicable  information  in  order  to  give  insight  into  the 
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capabilities  and  objectives  of  the  processes.  (Including  a  complete  view  of  the  foundry  interface 
possibilities.) 

Foundry  Interface  Specification 

A  “Foundry  Interface  Specification”^]  defines  the  information  requirements  of  the  foundry  for 
applicable  product  and  service  offerings.  This  is  a  reference  guide  used  within  the  foundry  to 
compile  all  methods  and  formats  for  communicating  required  information  and  a  description  of  the 
relative  degree  of  effort  needed  to  process  different  options. 

The  presumption  is  that  a  superset  of  all  communication  options  supplied  in  various  design  kits,  as 
well  as  potential  stand  alone  paths,  is  described  in  the  interface  document.  Since  this  is  a  foundry 
internal  document,  it  also  maintains  data  processing  procedures  and  individual  path  concerns  for 
reference  purposes. 

Design  Ground  Rules  Document 

A  “Design  Ground  Rules”  [6]  document  is  the  description  of  all  technology  specific  manufacturing 
requirements,  (e.g.  line  &  vias  sizes,  spacings)  The  document  is  CAD-tool-independent  and  drives 
the  definition  of  parameters  and  information  for  the  tool  specific  design  kit.  Referencing  Figure 
2.2-4,  this  would  be  the  'D'  information  which  a  design  is  compared  against  when  it  is  received  at 
the  foundry.  Every  design,  whether  originated  from  a  design  kit  or  not,  is  compared  with  the 
requirements  of  Design  Ground  Rules  document  before  beginning  manufacturing.  The  “Design 
Ground  Rules”  is  used  to  define  the  latest  understanding  of  technology  requirements  and  as  new 
capabilities  arise  will  be  the  first  to  be  updated. 

2.2.2.3  Specification  Level 

Functional  requirements  are  needed  to  enter  the  foundry  at  this  stage.  The  kit  specification  goes 
into  detail  describing  specific  elements  that  support  the  specification  level  of  entry  within  the  broad 
categories  of  ‘Rules,  Models,  Libraries,  Design  Tool  Parameter  Settings’  and  ‘Specialized 
Software’.  Since  at  this  time  software  tools  are  not  supported,  support  offered  in  the  kit  is  the 
documentation  of  technology  capabilities  for  reference  by  customers.  Part  of  that  documentation  is 
a  checklist  that  is  provided  to  remind  customers  of  various  domain  specifications  that  may  be 
important  to  a  customer  application  and  should  be  conveyed  to  the  foundry.  Another  part  of  the 
documentation  describes  typical  business  interaction  contacts  and  the  overall  program  process 
flow. 

2.2.2.4  Logic  Level 

The  kit  documentation  describes  the  requirements  to  enter  the  foundry  at  the  logic  entry  level.  Not 
only  is  logic  information  needed,  a  subset  of  system  specification  information  is  also  required. 

The  kit  specification  goes  into  detail  describing  specific  elements  that  support  the  logic  level  of 
entry  within  the  broad  categories  of  ‘Rules,  Models,  Libraries,  Design  Tool  Parameter  Settings’ 
and  ‘Specialized  Software’. 

Generally  the  elements  describe  the  following: 

•  Abstractions  of  typical  package  information,  made  available  to  assure  that  the  logic  design  can 
map  to  a  physical  design  solution.  An  example  would  be  the  provision  of  a  typical  signal  time- 
of-flight  that  could  be  used  to  check  acceptable  chip  to  chip  delays  vs.  a  technology  option. 

•  Logic  symbols  for  standard  MCM  I/O  configurations 
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•  Testability  issues  -  identified  in  the  kit  with  the  reference  to  the  ‘ASEM  Report  on  Testability 
Strategy  and  Guidelines’ [7] 

•  Guidance  on  information  required  for  passage  to  the  physical  design  stage 

•  Business  interaction  information  -  included  to  assist  in  providing  customers  with  additional 
support. 

2.2.2.5  Physical  Level 

The  kit  documentation  describes  the  requirements  to  enter  the  foundry  at  the  physical  entry  level. 
Not  only  is  physical  information  needed,  some  elements  of  the  specification  and  logic  design  are 
also  required.  The  kit  specification  goes  into  detail  describing  specific  elements  that  support  the 
physical  level  of  entry  within  the  broad  categories  of  ‘Rules,  Models,  Libraries,  Design  Tool 
Parameter  Settings’  and  ‘Specialized  Software’. 

Generally  the  elements  describe  the  following: 

•  Library  support  for  template  MCM's  (board),  I/O  footprints,  standard  padstacks,  and  sample 
die  footprints,  common  automation  scripts  and  environment  controls,  and  on-line 
documentation  for  methodology  support,  technology  descriptions,  and  customer  support 

•  MCM  Templates  include  information  about  the  substrates  and  assembly  items  such  as;  design 
rules,  material  descriptions  (electrical,  thermal,  geometrical),  package  size  &  initial  cross 
section,  module  features  (cap  seal  band,  fiducials),  and  device  placement  region 

•  Automated  Design  Flows  to  guide  design  personnel,  as  available 

•  Release  information  needed  for  the  manufacturing  environment 

2.2.2.6  Summary  Per  Design  Phase 

Given  the  types  of  data,  documentation,  tool  specific  data,  and  custom  software,  this  section  of  the 

report  provides  an  example  of  kit  content  relative  to  the  conceptual,  logic,  and  physical  design 
phases. 

During  the  conceptual  design  phase,  product  characteristics  are  defined.  Definitions  include  size, 
weight,  testability,  reliability,  environment,  cost,  and  a  host  of  other  potential  product 
characteristics.  Product  characteristics  are  described  in  the  documentation  that  accompanies  the 
kit.  The  documentation  also  includes  a  design  checklist  that  summarizes  this  information  for 
shipment  to  the  a  foundry  in  a  defined  format.  When  commercial  tools  (trade-off  tools)  become 
sufficiently  utilized  to  support  decisions  at  the  conceptual  design  level,  the  technology 
characteristic  data  can  be  migrated  to  the  tool  data  formats.  In  the  future,  custom  software  may 

also  be  written  to  assist  in  product  definition.  A  more  complete  view  of  Conceptual  design  can  be 
found  in  reference  [8], 

During  the  logic  design  phase,  custom  chips  may  be  designed  or  standard  chips  may  be 
interconnected  and  simulated  to  verify  the  intended  function.  At  this  stage,  the  logic  must  be 
partitioned  into  blocks  that  are  supportable  by  the  MCM  technology  that  is  selected.  Included  in 
the  kit  is  documentation  that  describes  the  I/O  capacity  of  standard  MCMs,  typical  package  delay 
characteristics,  the  standard  information  and  netlist  interfaces  to  the  physical  design  phase,  and  a 
format  for  conveying  die  information  (the  ARPA  sponsored  DIE  format  [4]).  With  regardi  to  tool 
specific  data,  connector  symbols  that  are  used  to  define  the  MCM  I/O  are  included  as  available,  as 
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well  as  an  example  of  a  die  in  the  DIE  format.  Future  custom  software  could  potentially  include 
customer-foundry  communication  software. 

During  the  physical  design  phase,  all  the  requirements  defined  in  both  the  conceptual  design  phase 
and  logic  design  phase  must  be  implemented.  The  design  kit  supports  these  requirements  by 
providing  documentation  describing  design  methodology,  technology  ground  rules,  and  foundry 
interface  information  such  as  the  information  needed  to  build  the  MCM  at  the  foundry,  and  data 
transfer  preferences.  Tool  specific  data  is  provided  in  the  form  of  library  elements  of  standard 
MCM  offerings  (templates)  and  design  tool  parameter  information  for  tool  controlled  design  rule 
checking  and  functions  (e.g.  Router).  Custom  software  is  provided  for  special  functions  deemed  by 
the  foundry  to  aid  in  the  design  of  an  MCM  which  is  consistent  with  the  technology  requirements 
(e.g.  custom  checks,  enhanced  power  plane  creation  utilities,  custom  process  flow  automation). 

Since  the  kit  originates  in  the  foundry,  the  information  supplied  to  help  the  customer  is  based  on 
the  foundry's  customer  set  experience,  which  is  continually  being  updated  as  more  information  is 
requested. 

2.2.3  Cadence  MCM-D  Design  Kit 

The  design  kit  for  the  IBM  MCM-D  process  was  assembled  around  the  previously  described  tools 
and  reviewed  with  the  kit  specification  in  mind.  The  kit  that  supports  the  Cadence  tools  is  titled 
‘MCM-D  Design  Kit  (1  of  2),  Using  the  Cadence  Allegro  Design  System’  dated  August  29,  1994 
[1],  The  documentation  follows  that  of  the  outline  described  in  the  specification  though  section 
titles  do  not  exactly  match.  The  difference  is  due  to  the  kit  specification  describing  levels  of 
support  that  are  not  provided  at  this  time. 

Information  in  the  Overview,  Technology  Description,  MCM  Foundry  Design  Services,  Additional 
MCM  Foundry  Services,  and  Conceptual  Design  Phases  are  common  to  all  the  design  kits  for  the 
MCM-D  technology  regardless  of  the  tool  set.  This  pattern  is  useful  because  as  new  tool  sets  are 
supported,  these  sections  are  directly  copied  into  the  new  document. 

2.2.3.1  Design  Overview 

This  is  the  first  tool  set  specific  section.  Here  specific  hardware  and  software  requirements  of  the 
specific  tool  set  are  described.  Tool  specific  setup  information  is  provided  along  with  a  design 
flow  that  is  basically  tool  independent. 

2.2.3.2  Logic  Design  Support 

This  section  is  very  similar  between  design  kits  since  the  difference  at  the  tool  level  is  the  design 
capture  tool  that  is  used  to  convey  the  netlist  and  netlist  performance  constraints.  MCM  I/O 
symbols  are  provided  for  Concept.  The  standard  output  files  from  Concept/P ACKAGER  to 
Allegro  are  described.  Technology  characteristics  such  as  I/O  capacity,  physical  size,  and 
propagation  delay,  that  can  be  used  as  first  order  determinators  of  whether  a  logic  design  will  map 
to  a  specific  MCM  implementation,  are  described  in  the  Technology  Description  section  of  the  kit. 

2.2.3.3  Physical  Design  Support 

As  identified  earlier,  physical  design  support  is  the  design  phase  that  is  most  tool  specific. 

2.2.3.3.1  Design  Process  Flow 

A  general  flow  chart  is  provided  describing  the  preferred  methodology  within  the  tool  set  and  is 
depicted  in  Figure  2.2-5. 
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Figure  2,2-5  Cadence  MCM-D  physical  design  flow 

Besides  the  flow  chart,  each  design  step  is  detailed  with  how  the  technology  maps  to  the  specific 
tool  set  and  design  elements.  An  example  of  this  is  Padstacks  (taken  directly  from  kit 
documentation): 


Pad  Stacks:  Pad  stacks  are  created  using  the  Allegro  Padstack  Editor  and  are  used  to  define 
pin/pad  information  for  all  surface  features.  A  separate  pad  stack  must  be  created  for  each  pin/pad 
that  has  any  variation  in  shape  or  size.  The  template  for  the  blind  and  buried  via  pad  stack  is  also 
defined  using  the  pad  stack  editor.  The  board  template  includes  all  necessary  blind  and  buried  via 
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stacks  for  the  given  cross  section.  The  only  pads  which  will  need  to  be  created  will  be  those 
required  for  specific  components. 

The  pad  stack  Layer  Type  should  be  Blind/Buried  for  all  pad  stacks  and  the  Inner  Layer  is  always 
set  to  Optional.  All  outer  surface  pads,  including  top  and  bottom  surface  features,  are  defined  as 
having  a  pin  location  of  Top  or  Bottom,  respectively. 

Wire  bond  and  tab  chip  pads  are  generally  shape  based  pads  where  the  shape  is  offset  to  move  the 
via  to  the  edge  of  the  pad  to  allow  more  room  for  interconnections,  see  Figure  6  on  page  32,  Figure 
7  on  page  33,  and  pad  examples  in  the  ./pads  directory, _ 

As  can  be  seen,  the  kit  defines  that  the  only  padstacks  that  should  need  to  be  created  are  those 
which  support  new  component  interconnection  requirements.  Details  of  how  to  create  Wire  Bond 
and  TAB  chip  pads  are  described  and  specific  design  kit  documentation  figures  are  referenced. 

Specifics  of  design  rules  controlled  within  the  tool  set  are  described  and  rules  that  are  not 
controlled  are  also  described.  The  rules  that  cannot  be  automatically  insured  within  the  tool  sets 
are  managed  with  methodology  steps  that  request  foundry  reviews  of  the  outcome  of  the  steps  (e.g. 
new  symbols,  padstacks,  and  top  surface  placement  information). 

2.2.3.3.2  Sample  Design 

Another  key  aspect  of  physical  design  support  is  the  provided  ‘Sample  Design’.  Instructions  are 
included  to  assist  designers  in  the  completion  of  the  sample  design  within  the  tool  set  using  the 
defined  parameters  and  rules.  From  the  kit  documentation: 

The  sample  design  provided  in  the  kit  is  intended  to  allow  practicing  with  the  design  kit  in  the 
layout  and  routing  of  MCM-D  substrates  to  be  fabricated  by  IBM  Micro-electronics.  The  demo 
design  includes  the  required  padstacks,  symbols,  programs  and  text  files  used  in  the  design  of  the 
40  mm  demo  substrate.  See  Example  Substrate  Design”  on  page  37  for  instructions  on  creating 
the  example  design. _ 

2. 2. 3.3. 3  Design  Output  Required  by  IBM  Microelectronics 

The  last  aspect  of  physical  design  that  is  specifically  defined  by  the  tool  set  is  the  format  of  the 
data  to  be  used  at  the  physical  design  entry  level  into  the  foundry.  The  text  below  was  extracted 
from  the  kit  documentation: 
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The  output  required  for  IBM  Microelectronics  to  manufacture  a  design  created  with  this  design  kit 
is  as  follows: 

•  Completed  Substrate  File:  The  *.brd  file  will  be  used  to  create  the  necessary  manufacturing 
data. 

•  Pad  and  Symbol  Files:  The  *.ssm,  *.pad,  and  *.dra  files  will  be  used  to  verify  the 
manufacturability  of  the  components  of  the  design. 

•  Design  Checklist:  An  ASCII  file,  design_checklist,  is  located  in  the  directory,  /ibm- 
lib/mcmd/verXX/text.  This  file  contains  a  checklist  template,  which  prompts  the  customer  for 
product  characteristic  information  requested  by  IBM  Microelectronics.  A  completed  checklist 
is  to  be  provided  to  IBM  Microelectronics. 

•  Any  required  module  test  data  (e.g.  BIST,  patterns). 

The  design  output  may  be  sent  to  IBM  Microelectronics  via  0.25”  tape,  8mm  tape,  or  e-mail  to  the 
Design  Kit  Support  Contact;  refer  to  “Technical  Contacts”  on  page  1  for  the  e-mail  address. _ 

The  pad  and  symbol  files  are  requested  only  to  aid  in  foundry  library  development  efforts. 

2.2.3.4  Design  Results 

Two  aspects  of  design  kit  usage  are  described.  One  being  cycle  time  measurements  of  various 
design  steps  and  the  other  being  process  learning  that  is  captured  in  design  methodology  and  tool 
set  up  improvements.  The  cycle  time  and  process  learning  results  shown  are  the  results  from 
controlled  experiments  conducted  within  the  foundry  using  the  design  kits.  Although,  kit  usage  by 
three  outside  organizations  has  resulted  in  designs  being  manufactured  that  met  customer 
requirements,  specific  cycle  time  and  process  learning  data  is  not  available. 

2.2.3.4.1  Cycle  Time  Comparisons 

The  following  outlines  the  cycle  time  learning  for  a  designer  new  to  using  the  Allegro  design  tool 
for  each  of  the  process  steps  involved  in  a  typical  design.  For  detailed  instructions  on  each  of  the 
processes  see  the  Allegro  Design  Manual.  [9] 

Padstacks: 

The  creation  of  regular  padstacks  using  the  Allegro  padstack  editor  is  straight  forward  and  does 
not  require  a  large  investment  in  time.  The  overall  time  involved  will  depend  on  the  number  of 
unique  padstacks  required  for  the  design.  Shape  padstacks  will  require  slightly  longer  since 
additional  process  steps  are  required. 

Symbols: 

Symbols  are  created  using  the  Allegro  symbol  editor.  The  time  required  to  create  a  symbol  will 
depend  on  the  number  of  I/O,  the  regularity  of  the  pattern  and  the  format  in  which  the  pad 
placement  data  is  provided.  If  DIE  format,  or  ASCII,  data  is  available,  it  can  be  used  to  create  a 
script  for  automatic  pin  placement  which  decreases  the  cycle  time. 

Logic  Input: 

If  the  logical  data  is  supplied  in  the  form  of  Concept  output  or  as  a  third  party  netlist  in  the  proper 
ASCH  format,  the  logic  input  process  takes  minutes.  If  there  are  inconsistencies  between  the  logic 
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and  the  symbols,  several  attempts  may  be  required  before  a  clean  logic  input  is  achieved.  If  the 
data  is  provided  in  another  format  which  requires  translation  or  reformatting,  the  time  for  logic 
input  can  become  a  significant  contributor  to  the  overall  cycle  time. 

Blind/Buried  Via  Generation: 

The  bbvia  command  creates  the  necessary  level-to-level  connection  options  quickly.  The  process 
does  not  add  appreciably  to  the  time  required  for  design. 

Symbol  Placement: 

Through  the  use  of  the  plctxt  command  the  symbol  placement  is  nearly  automatic.  The  application 
engineer  provides  a  proposed  outline  for  component  placement  which  is  used  to  create  the 
placement  text  file.  This  allows  placement  of  the  components  to  occurs  in  seconds.  If  further 
trade-off  research  is  required  to  determine  the  correct  placement,  the  placement  time  will  be 
extended. 

Manual  Redistribution: 

Pad  locations  must  be  moved  from  off-grid  to  on-grid  positions.  There  is  now  an  automated 
SKILL  routine  to  assist  in  MCM-D  pin  redistribution,  and  this  can  be  completed  in  minutes.  In 
some  cases,  though,  redistribution  is  still  a  manual  process  and  can  be  quite  time  consuming 
depending  on  the  complexity  and  density  of  the  chip  I/O  pattern  and  the  ability  to  copy  the 
redistribution  between  identical  chips. 

Z-Router: 

For  multilayer  ceramic  designs,  the  z-router  command  provides  a  means  to  quickly  add  vias 
connecting  the  I/O  pads  to  the  internal  mesh  and  personality  layers.  Total  time  to  complete  this 
process  is  not  significant. 

Auto  Router: 

The  automatic  router  quickly  provides  the  connectivity  required  by  the  design  logic.  Several 
attempts  at  automatic  routing,  requesting  specific  regions  or  nets  be  connected  first,  may  improve 
the  completion  percentage  and  channel  utilization  provided  by  the  automatic  router.  This  process 
is  one  of  the  significant  contributors  to  overall  design  time.  While  the  computing  time  is 
significant,  the  designer  can  typically  multi-task  while  the  design  tool  accomplishes  the  routing. 

Overflow  Routine: 

If  the  automatic  router  cannot  complete  all  connections  required,  the  additional  nets  may  require 
routing  manually.  For  all  but  the  simplest  designs  there  is  typically  some  overflow  routing  which 
must  be  added.  Depending  on  the  density  of  the  routing  already  in  place  this  process  can  add 
appreciably  to  the  design  cycle  time.  Total  time  involved  will  depend  on  the  number  of  nets 
requiring  hand  routing  and  the  complexity  of  the  design. 

Mesh  Plane  Generation: 

The  Autovoid  and  Shape  features  of  the  Allegro  Design  tool  make  mesh  plane  generation  and 
connectivity  simple.  The  shape  based  process  does  not  add  significantly  to  the  design  cycle  time. 
For  mixed  redistribution  and  mesh  planes,  the  shape  based  process  could  not  create  a  plane  that 
was  processable  in  the  foundry  so  a  SKILL  routine  was  written  to  automatically  create  the  plane 
correctly.  Cycle  time  using  the  SKILL  program  is  dependent  on  the  size  of  the  module  and  the 
mesh  grid  and  can  usually  complete  within  a  couple  of  hours. 
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GL1  Out  Process: 


The  GL1  out  facility  provides  a  quick  means  of  translating  the  Allegro  design  data  into  the  format 
required  for  IBM  checking  and  conversion  to  manufacturing  data  format.  Three  simple  text  files 
must  be  created  which  outline  the  parameters  required  for  the  design  levels  (cross  section),  shapes 
(features)  and  line  end  characteristics.  This  process  can  take  a  couple  of  hours. 

Cycle  Time: 

Detailed  information  for  the  cycle  times  required  for  an  inexperienced  designer  to  complete  the 
above  process  steps  is  given  in  Table  2.2-4.  These  cycle  times  are  for  various  revisions  of  the 
Milpitas  (Sun  Microsystems)  design  which  are  defined  as  follows: 

•  MilpitasO-preliminary  design  to  determine  layout  and  routing  parameters  before  all  design  data 
was  available 

•  Milpitas  1 -initial  design 

•  Milpitas2-new  SRAM  design 

•  Milpitas3-new  test  net  requirements 
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2.2.3.4.2  Process  Learning 

Through  these  design  experiences,  updates  were  made  to  most  sections  of  the  design  methodology 
and  kit  documentation.  Later  design  experiences  showed  fewer  (and  less  significant)  updates  were 
needed  for  effective  tool  utilization. 

2.2.3.4.3  Cadence  Design  Kit  Conclusions 

The  data  presented  documents  significant  cycle  time  reduction  capability  that  supports  the 
assertion  that  a  five  day  netlist-to-physical-design  cycle  is  possible.  In  simple  cases  the  netlist-to- 
physical-design  cycle  has  been  demonstrated  in  less  time. 

In  addition  to  use  of  the  design  kit  at  IBM,  products  have  been  built  with  design  data  created  by 
ISI,  McClellan  Air  Force  Base  Air  Logistics  Center,  and  other  customers  who  have  used  the  design 
kit,  further  proving  the  kit  effectiveness. 

2.2.4  Mentor  Graphics  MCM-D  Design  Kit 

The  design  kit  for  the  IBM  MCM-D  process  was  assembled  around  the  previously  described  tools 
and  reviewed  with  the  kit  specification  in  mind.  The  kit  that  supports  the  Mentor  Graphics  tools  is 
titled  ‘MCM-D  Design  Kit  (2  of  2),  Using  the  Mentor  Graphics  MCM  Station  Design  System’ 
dated  August  29, 1994.  [2]  The  documentation  follows  that  of  the  outline  described  in  the 
specification  though  section  titles  do  not  exactly  match.  The  difference  is  due  to  the  kit 
specification  describing  levels  of  support  that  are  not  provided  at  this  time. 

Information  in  the  Overview,  Technology  Description,  MCM  Foundry  Design  Services,  Additional 
MCM  Foundry  Services,  and  Conceptual  Design  Phases  are  common  to  all  the  design  kits  for  the 
MCM-D  technology  regardless  of  the  tool  set.  This  pattern  is  useful  because  as  new  tool  sets  are 
supported,  these  sections  are  directly  copied  into  the  new  document. 

2.2.4. 1  Design  Overview 

This  is  the  first  tool  set  specific  section.  Here  specific  hardware  and  software  requirements  of  the 
specific  tool  set  are  described.  Tool  specific  setup  information  is  provided  along  with  a  design 
flow  that  is  basically  tool  independent. 

2.2.4.2  Logic  Design  Support 

This  section  is  very  similar  between  design  kits  since  the  difference  at  the  tool  level  is  the  design 
capture  tool  that  is  used  to  convey  the  netlist  and  netlist  performance  constraints.  MCM  I/O 
symbols  can  be  provided  for  Design  Architect.  The  standard  output  files  from  Design 
Architect/Package  to  MCM  Station  are  described.  Technology  characteristics  such  as  I/O 
capacity,  physical  size,  and  propagation  delay,  that  can  be  used  as  first  order  determinators  of 
whether  a  logic  design  will  map  to  a  specific  MCM  implementation,  are  described  in  the 
Technology  Description  section  of  the  kit. 

2.2.4.3  Physical  Design  Support 

As  identified  earlier,  physical  design  support  is  the  design  phase  that  is  most  tool  specific. 

2.2.4.3.1  Design  Process  Flow 

A  general  flow  chart  is  provided  describing  the  preferred  methodology  within  the  tool  set  and  is 
depicted  in  Figure  2.2-6: 
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Figure  2.2-6  Mentor  Graphics  MCM-D  physical  design  flow 

Besides  the  flow  chart,  each  design  step  is  detailed  with  how  the  technology  maps  to  the  specific 
tool  set  and  design  elements.  An  example  of  this  is  Pin  Geometries  (taken  directly  from  kit 
documentation): 
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Pin  Geometries: 

Pin  Geometries  are  created  in  LIBRARIAN  to  define  pin  and  via  geometries.  A  separate  padstack 
is  created  for  each  pin  or  via  that  has  any  variation  in  shape,  size,  or  layer  of  build.  Top  and 
bottom  surface  pads,  including  I/O,  C4,  wirebond,  and  TAB  pads,  are  defined  as  surface  pins. 
Vias  are  defined  as  buried  vias,  and  are  created  on  the  generic  layers,  signal,  power,  and 
sheet_dielectnc.  All  vias  have  been  defined  in  the  pin  geometry  library.  The  only  pad  pins  that  will 
need  to  be  created  are  ones  for  specific  components. 

Wire  bond  and  tab  chip  pads  are  generally  shape  based  pads  where  the  shape  is  offset  to  move  the 
via  to  the  edge  of  the  pad  to  allow  more  room  for  the  interconnection,  see  Figure  7  on  page  36  and 
Figure  8  on  page  37  for  pad  examples. 

Surface  pads  do  not  have  pin  rules.  Buried  vias  have  via  rules  that  define  the  layers  the  vias  may 
attach  to  single  layer  pads,  and  define  the  start  and  stop  layers  for  the  vias.  A  start/stop  rule  must 
be  defined  for  each  permutation  of  the  layers  that  the  via  can  span.  For  MCM-D  technology,  the 
start  and  stop  layers  must  be  adjacent  signal  layers.  That  is,  vias  must  only  span  through  one 
sheet_dielectric  layer.  All  of  the  via  rules  necessary  to  design  an  MCM  have  been  included  in  the 
Tech  file. 

To  access  the  padstacks  stored  in  the  IBM  geometry  library,  establish  a  link  to  the  directory, 
ibm_geom_lib,  using  the  command  found  in  LIBRARIAN,  under  the  geometry  pull-down  menu. 

As  can  be  seen,  the  kit  defines  that  the  only  pin  geometries  that  should  need  to  be  created  are  those 
which  support  new  component  interconnection  requirements.  Details  of  how  to  create  Wire  Bond 
and  TAB  chip  pads  are  described  and  specific  design  kit  documentation  figures  are  referenced. 

Specifics  of  design  rules  controlled  within  the  tool  set  are  described  and  rules  that  are  not 
controlled  are  also  described.  The  rules  that  cannot  be  automatically  insured  within  the  tool  sets 
are  managed  with  methodology  steps  that  request  foundry  reviews  of  the  outcome  of  the  steps  (e.g. 
new  components,  pin  geometries,  and  top  surface  placement  information). 

2.2A3.2  Sample  Design 

Another  key  aspect  of  physical  design  support  is  the  provided  ‘Sample  Design’.  Instructions  are 
included  to  assist  designers  in  the  completion  of  the  sample  design  within  the  tool  set  using  the 
defined  parameters  and  rules.  From  the  kit  documentation: 
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The  sample  design  provided  in  the  kit  is  intended  to  allow  practicing  with  the  design  kit  in  the 
layout  and  routing  of  MCM-D  substrates  to  be  fabricated  in  the  IBM  East  Fishkill  Foundry.  The 
demo  design  includes  the  required  padstacks,  components,  and  pcb  design  objects  used  in  the 
design  of  the  40  mm  demo  substrate.  To  view  the  design,  invoke  the  appropriate  MCM  Board  or 
MCM  Station  tools  on  the  design  directory,  ibm_demo. 

For  illustration  purposes  only,  ground  plane  cutouts  of  the  hatched  area  fill  are  depicted  as  cutouts 
beneath  complete  arrays  of  wirebond  and  TAB  pads.  Individual  pad  cutouts  are  also  depicted  on 
the  ground  plane  beneath  the  array  of  wirebond  pins  A02-AA04  -  A02-AA75,  located  from  (15.98, 
-4.8875)  to  (15.98,  -13.3475),  and  the  array  A02-AB07  -  A02-AB73  located  from  (15.38,  -5.24) 
to  (15.38,  -12.995), _ 

2.2.4.3.3  Design  Output  Required  by  IBM  Microelectronics 

The  last  aspect  of  physical  design  that  is  specifically  defined  by  the  tool  set  is  the  format  of  the 
data  to  be  used  at  the  physical  design  entry  level  into  the  foundry.  The  text  below  was  extracted 
from  the  kit  documentation: 

The  output  required  for  IBM  Microelectronics  to  manufacture  a  design  created  with  this  design  kit 
is  as  follows: 

•  Manufacturing  directory:  The  /pcb/mfg  directory  from  the  completed  design  will  contain  the 
GERBER  output  for  the  layers,  which  will  be  submitted  to  IBM  for  processing.  The  mfg 
directory  will  also  contain  the  neutral  file,  neutral_file,  which  contains  board  attributes  data, 
components  data,  geometries  and  pads  data,  and  nets  data. 

•  Tech  file:  The  /pcb  directory  in  the  design  directory  will  contain  up  to  the  three  latest  versions 
of  the  tech  file.  The  newest  version  of  the  tech  file,  the  tech  file  with  the  greatest  version 
number,  is  to  be  sent  to  IBM  Microelectronics. 

•  Design  Checklist:  An  ASCII  file,  design_checklist,  is  located  in  the  directory,  /ibm- 
Ub/mgc/mcmd/verXX/text.  This  file  contains  a  checklist  template,  which  prompts  the  customer 
for  product  characteristics  information  requested  by  IBM  Microelectronics.  A  completed 
checklist  is  to  be  inputted  to  IBM  Microelectronics. 

•  Any  required  module  test  data  (e.g.  BIST,  patterns) 

The  design  output  may  be  sent  to  IBM  Microelectronics  via  0.25”  tape,  8mm  tape,  or  e-mail  to  the 
Design  Kit  Support  Contact;  refer  to  “Technical  Contacts”  on  page  1  for  the  e-mail  address. _ 

As  can  be  seen  by  these  preferences,  Gerber  output  from  Mentor  Graphics  is  better  suited  for 
processing  within  the  foundry. 

2.2.4.4  Design  Results 

Two  aspects  of  design  kit  usage  are  described.  One  being  cycle  time  measurements  of  various 
design  steps  and  the  other  being  process  learning  that  is  captured  in  design  methodology  and  tool 
set  up  improvements.  The  cycle  time  and  process  learning  results  shown  are  the  results  from 
controlled  experiments  conducted  within  the  foundry  using  the  design  kits. 

The  IBM  design  kit  experience  using  the  Mentor  Graphics  tool  set  is  based  on  three  design  cases. 
MLC-1  and  2  are  test  cases  that  were  also  used  with  the  Cadence  tool  set  to  get  an  understanding 
of  the  base  tool  capabilities.  The  last  design  case  was  TF-1  which  is  a  mapping  of  the  thin  film 


2-38 


technology  that  the  design  kit  was  built  on.  Results  show  the  expected  cycle  times  for  designers 
having  various  levels  of  experience  with  the  tools  and  technology. 

2.2.4.4.1  Cycle  Time  Comparisons 

The  IBM  MCM-C  and  MCM-D  technologies  were  mapped  into  the  Mentor  Graphics  MCM  Board 
Station  Design  System  with  a  17mm  substrate  composed  of  nine  chip  sites  and  36  signal  nets. 

This  design  was  also  used  to  map  IBM  technology  into  the  Allegro  Design  System,  and  therefore, 
provided  a  model  for  mapping  the  IBM  technologies  into  Mentor  Graphics.  This  document  records 
the  cycle  times  for  three  iterations  of  the  design:  MLC1,  a  first  attempt  to  map  the  IBM  MLC 
technology  into  Mentor  Graphics;  MLC2,  a  second  pass  at  mapping  the  MLC  technology  after  the 
technology  was  reviewed  with  the  Mentor  Graphics  Benchmark  team;  and  TF-1,  a  mapping  of  the 
IBM  thin  films  technology  into  the  Mentor  Graphics  MCM  Board  Station  Design  System. 

The  following  subsections  outline  the  cycle  time  learning  for  an  inexperienced  designer  using  the 
Mentor  Graphics  design  tools  for  each  of  the  process  steps  involved  in  a  typical  design.  For 
detailed  instructions  on  each  of  the  processes  refer  to  the  Mentor  Graphics  Design  Methodology 
Manual.  [10] 

Padstacks: 

The  creation  of  regular  shaped  padstacks,  i.e.,  circle,  square,  rectangle,  is  a  straight  forward 
process  in  Librarian,  and  should  not  require  a  large  investment  in  time.  The  overall  time  involved 
will  depend  on  the  number  of  unique  padstacks  required  for  the  design.  Custom  shaped  padstacks 
will  require  more  time  since  some  additional  process  steps  are  required  to  draw  the  shapes. 

The  difficulty  in  creating  pin  padstacks  for  the  first  design,  MLC1,  was  in  selecting  the  type  of  pin 
padstack  to  create:  blind,  surface  or  through  pin.  Padstacks  in  the  Allegro  system  were  created  as 
blind  pins.  Initial  advice  was  to  create  the  pin  padstacks  as  blind  pins.  The  blind  pins  resulted  in 
routing  problems  in  Layout,  because  vias  could  not  be  added  beneath  blind  pins.  The  MLC2  and 
TF-1  designs  were  created  using  surface  pin  padstacks. 

Components: 

Components  are  created  in  Librarian.  The  time  required  to  create  a  component  will  depend  on  its 
number  of  padstacks,  such  as  I/O  pads,  the  regularity  of  the  pattern  and  the  format  in  which  the 
pad  placement  data  is  provided.  The  placement  data  may  be  directly  edited  into  the  ASCII 
geometry  file  for  automatic  pin  placement  which  decreases  the  cycle  time.  Similarly  if  data  is 
supplied  in  the  DIE  format,  or  other  ASCII  format,  this  process  cycle  time  can  be  significantly 
reduced. 

Board: 

The  board  geometry  is  created  in  Librarian  within  minutes  and  is  not  a  significant  contributor  to 
cycle  time. 

Logic  Input: 

If  the  logical  data  has  already  been  supplied  as  Design  Architect  output  or  as  a  third  party  netlist 
and  a  comps  file  in  ASCII  format,  the  logic  input  process  takes  minutes.  If  there  are 
inconsistencies  between  the  logic  and  the  components,  several  attempts  may  be  required  before  a 
clean  logic  input  is  achieved.  If  the  data  is  provided  in  another  format  which  requires  translation  or 
reformatting,  the  time  for  logic  input  can  become  a  significant  contributor  to  the  overall  cycle  time. 

Part  Numbers: 
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Part  numbers,  which  provide  descriptions  of  physical  devices  used  in  the  board  design,  are  quickly 
created  in  Librarian  and  do  not  contribute  significantly  to  the  design  cycle  time. 

Mapping  Files: 

Mapping  files,  in  which  physical  component  pins  are  mapped  to  logic  symbol  pins,  are  created  in 
Librarian.  The  cycle  time  to  create  a  mapping  file  depends  on  the  number  of  component  pins. 

Package: 

Packaging  the  design  is  a  simple  process  that  does  not  consume  considerable  cycle  time.  The 
output  from  Package  is  used  by  Layout. 

Design  Rules: 

Creating  the  design  rules  entails  defining  the  board  physical  layers  cross  section,  defining  via  and 
pin  padstack  rules,  and  routing  constraints.  The  cycle  time  to  define  the  design  rules  will  be  a 
function  of  the  number  of  physical  layers,  and  the  number  of  padstacks  that  require  rules 
definition.  Blind  pins  and  blind  vias  require  rules,  while  surface  pins  do  not.  Copying  and 
modifying  an  existing  ASCII  tech  file  reduces  the  cycle  time  for  defining  design  rules.  These  rules 
are  included  with  the  design  kit  so  a  customer  does  not  have  to  perform  this  step,  just  utilize  the 
template  provided. 

Component  Placement: 

Component  placement  can  be  done  interactively,  automatically,  or  by  placing  component 
coordinates  into  the  comps  file  directly.  Interactive  routing  is  the  most  time  consuming  of  the  three 
processes. 

Redistribution: 

Redistribution  is  required  to  move  pad  locations  from  off-grid  to  on-grid  positions.  Redistribution 
can  be  done  manually  or  automatically,  although  using  the  autorouter  requires  significant 
manipulation  of  the  router  through  the  use  of  autofill  areas  and  route  keepouts.  In  either  case,  the 
redistribution  process  can  be  quite  time  consuming  depending  on  the  complexity  and  density  of  the 
chip  I/O  pattern  and  the  ability  to  copy  redistribution  layouts  between  identical  chips. 

A  number  of  alternatives  were  tried  before  determining  that  die  components  must  be  partially 
manually  routed  to  get  the  redistribution  to  work  properly.  In  the  future.  Ample  code  could  be 
written  to  help  support  this  requirement. 

Auto  Router: 

The  automatic  router  quickly  provides  the  connectivity  required  by  the  design  logic.  Several 
attempts  at  automatic  routing,  requesting  specific  regions  or  nets  be  connected  first,  may  improve 
the  completion  percentage  and  channel  utilization  provided  by  the  automatic  router.  This  process 
is  one  of  the  significant  contributors  to  overall  design  time.  While  the  computing  time  is  significant, 
the  designer  can  typically  multi-task  while  the  design  tool  accomplishes  the  routing.  The  designs 
completed  to  date  have  been  simplified,  and  therefore,  autorouting  did  not  consume  significant 
cycle  time. 

Overflow  Routing: 

If  the  automatic  router  cannot  complete  all  connections  required,  the  additional  nets  may  require 
routing  manually.  For  all  but  the  simplest  designs  there  is  typically  some  overflow  muting  which 
must  be  added.  Depending  on  the  density  of  the  routing  already  in  place  this  process  can  add 
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appreciably  to  the  design  cycle  time.  Total  time  involved  will  depend  on  the  number  of  nets 
requiring  hand  routing  and  the  complexity  of  the  design. 

Mesh  Plane  Generation: 

Mesh  planes  are  easily  generated  in  either  the  Layout  or  FabLink  tools  using  the  areafill  command. 
Total  time  to  complete  this  process  is  not  significant 

Mesh  planes  were  not  generated  for  the  MLC1  design,  because  the  methodology  to  build  power 
planes,  and  to  generate  hatched  planes  with  orthogonal  cutouts  was  not  understood  at  the  time  the 
design  was  mapped. 

Use  of  the  FabLink  option  to  remove  partial  hatch  from  the  Gerber  allowed  appropriate  creation  of 
cut  out  around  signal  wiring  on  the  redistribution-mesh  plane.  The  partial  hatch  is  not  removable 
from  GDS2  output  and  therefore  causes  processing  difficulties  at  the  foundry. 

Gerber  Output: 

The  FabLink  application  is  used  to  create  artwork  in  Gerber  format  for  input  into  the  IBM 
foundry.  The  template  contains  an  existing  artwork  format  file  in  the  design  directory.  The 
aperture  table  is  also  be  supplied  in  the  kit,  but  generating  it  automatically  from  the  design 
information  is  better  because  the  automatic  generation  creates  apertures  for  new  pad  shapes.  Once 
these  files  are  created,  the  artwork  is  generated  quickly. 

Cycle  Time: 

Detailed  information  for  the  cycle  times  required  for  an  inexperienced  designer  to  complete  the 
above  process  steps  is  given  in  Table  2.2-5.  These  cycle  time  are  for  various  revisions  of  the 
17mm  demo  used  to  debug  the  design  methodology  for  IBM  MCM-C  and  MCM-D  technologies 
and  are  defined  as  follows: 

•  MLC 1  -  preliminary  design  to  debug  design  methodology  for  routing  the  MLC  technology; 
basic  knowledge  of  Board  Station  tools,  but  MCM-hybrid  technology  mapping  not  fully 
understood  since  the  User's  Manual  and  technical  support  were  geared  towards  PCB 
technology. 

•  MLC2  -  second  mapping  of  MLC  technology  into  Mentor  Graphics,  following  a  meeting  with 
the  Mentor  Graphics  Benchmark  team.  Custom  Ampleware  programs  were  written  to  improve 
routability  and  design  process,  but  not  used  for  this  design. 

•  TF-1  -  preliminary  mapping  of  thin  films  technology  into  Mentor  Graphics  Board  Station. 
Design  generated  after  meeting  with  Mentor  Graphics  Benchmark  team.  The  cycle  time  for 
this  design  was  shortened  because  elements  of  the  MLC2  design  were  used  for  the  TF1  design. 
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2.2AA.2  Process  Learning 

Through  these  design  experiences,  updates  were  made  to  most  sections  of  the  design  methodology 
and  kit  documentation.  Later  design  experiences  showed  fewer  (and  less  significant)  updates  were 
needed  for  effective  tool  utilization. 

2.2.4.4.3  Mentor  Graphics  Design  Kit  Conclusions 

The  data  presented  documents  significant  cycle  time  reduction  capability  that  supports  the 
assertion  that  a  five  day  netlist-to-physical-design  cycle  is  possible.  No  additional  products  have 
been  built  specifically  from  this  design  kit  at  this  time. 

2.2.5  Design  Kit  Section  Conclusions 

Design  kits  have  been  provided  to  support  the  IBM  MCM-D  technology.  The  use  of  design  kits 
has  demonstrated  that  the  kits  can  effectively  aid  in  conveying  the  necessary  technology 
information  required  to  understand  and  implement  products  in  a  cost  and  time  effective  manner. 

2.2.5. 1  General  Observations 

In  a  perfect  world,  only  one  design  kit  should  be  needed  for  each  technology,  however,  because  of 
the  uniqueness  of  tools  and  their  database  formats,  design  kits  currently  are  required  to  be 
personalized  in  order  to  support  specific  tool  sets.  Design  kits  can  enhance  the  utility  and 
applicability  of  design  systems  while  also  transferring  foundry  technology  information  to  MCM 
Design  engineers.  The  content  and  format  of  current  design  kits  are  expected  to  be  enhanced  to 
include  additional  information  requests  from  customers.  Future  kit  extensions  will  be  driven  by 
market  demands. 

Regular  kit  support  requires  continuing  tool  expertise.  Kit  support  also  requires  updates  reflecting 
current  technology  offerings  and  foundry  information  such  as  information  in  Design  Ground  Rules, 
Foundry  Interface  Specifications,  and  Foundry  User’s  Guides.  It  also  expects  that  foundries  will 
continue  to  support  new  releases  of  tools  which  improve  the  user’s  capability  to  verify  and  validate 
design  conformance  to  manufacturability  requirements. 

2.2. 5.2  Design  Tool  Support  Observations 

Certain  tool  limitations  were  identified  in  the  process  of  creating  the  first  (MCM-C)  design  kit. 
These  limitations  were  identified  to  the  EDA  companies  and  work  began  to  find  short  and  long 
term  solutions  to  the  problems.  The  limitations  were  mainly  in  two  areas;  Routing  rthannftl  control 
and  mesh  plane  generation.  Routing  channel  control  was  mainly  a  MCM-C  issue  while  the  mesh 
plane  requirements  had  to  be  addressed  for  both  'C'  and  'D'  technology. 

Routing  channel  control  is  an  issue  for  two  reasons.  Controlling  line  position  relative  to  a  mesh 
plane  position  reduces  the  variation  in  electrical  parameters  of  the  lines  on  an  MCM.  Secondly,  for 
the  IBM  MCM-C  technology,  creating  the  X,  Y  routing  with  the  'under  mesh'  control  maintains  the 
impedance  described  in  the  kit.  While  Cadence  tools  did  support  these  requirements,  the  Mentor 
Graphics  tools  did  not. 

The  mesh  plane  limitation  has  to  do  with  the  way  short  signal  line  redistributions  on  the  mesh 
planes  are  isolated  from  one  another.  Initially,  the  Cadence  tool  did  not  support  rectangular 
isolation  areas  surrounding  the  signal  lines  but  this  was  ultimately  solved  with  a  SKILL  program. 
Mentor  Graphics  did  support  this  capability  by  the  elimination  of  stubs  from  the  mesh  plane 
artwork  (Gerber  only). 
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In  the  process  of  creating  the  MCM-D  design  kits,  a  general  understanding  arose  as  to  the  kind  of 
information  required  for  a  design  kit.  This  information  is  described  in  the  'Design  Kit 
Specification'.  Given  unlimited  resources,  all  the  items  discussed  in  the  kit  specification  could  be 
implemented  for  customers.  It  is  also  true  that  design  systems  that  are  supported  with  extension 
languages,  such  as  SKILL  or  Ample,  can  overcome  many  of  the  base  function  limitations  that  may 
have  precluded  them  from  supporting  technology  requirements.  Extension  language  capability  is 
one  of  the  key  capabilities  to  look  for  in  choosing  MCM  design  system  software. 

The  design  kit  specification  outlines  the  type  of  information  needed  to  describe  MCM  technology 
for  the  physical  design  phase,  logic  design  phase,  and  specification  development  phase  of  prototype 
development.  Three  general  classifications  of  information  are  necessary;  documentation,  tool 
specific  data,  and  custom  software. 

•  The  documentation  includes  text  and  visual  support  information  to  describe  the  technology  and 
business  requirements  of  customer  foundry  relationships. 

•  Tool  data  relates  to  information  specifically  developed  to  initialize  or  control  the  design  tools. 
Examples  are  minimum  and  maximum  feature  spacing,  template  boards,  and-or  router 
controls. 

•  Custom  software  defines  special  programs  to  support  technical  and  business  activity  related  to 
the  MCM  process.  Examples  are  design  automation  routines  and  data  exchange  software. 

MCM  Design  Tool  capability,  and  IBM  experience  with  the  tools,  developed  to  the  point  where 
MCM-D  design  kits  were  developed  for  both  the  Cadence  and  Mentor  Graphics  Corporation 
design  tools.  Copies  of  the  MCM-D  design  kits  were  delivered  as  part  of  the  contract.  Cadence  and 
Mentor  Graphics  kits  were  transferred  to  foundry  personnel  in  order  to  continue  development  and 
extensions  to  the  kits  to  incorporate  extensions  in  die  foundry  standard  offerings.  This  is  best 
exemplified  by  the  extension  of  the  MCM-C  kit  from  a  single  64mm  package  to  a  product  range  of 
1 8  to  64mm,  solder  grid  array-pin  grid  array,  hermetic-non-hermetic,  and  capped-cap-less 
modules,  see  reference  [11]. 

Initial  feedback  on  the  initial  design  kit  offering  was  that  it  needed  to  be  more  user  friendly  where 
the  friendliness  was  determined  by  the  ease  of  locating  information  in  the  documentation  and  the 
naturalness  of  the  detailed  design  steps.  Initial  problem  areas  were  the  documentation,  the  number 
of  non-standard  or  non-intuitive  design  steps,  and  the  ease  of  the  interface  to  those  non-standard 
design  steps  that  were  required  of  the  design  engineer.  This  was  taken  into  account  with 
clarification  and  the  restructuring  of  information  in  subsequent  releases.  Efforts  to  further 
automate  the  insertion  of  technology  requirements  into  the  tool  specific  design  processes  will 
continue  to  improve  usability.  The  automation  ranges  from  improving  a  tool  set's  ability  to 
implement  technology  requirements  (e.g.  mesh  planes,  via  requirements)  to  improving  forms 
interfeces  for  the  customer's  use.  Since  this  is  a  continuing  evolution  of  technology  and  tools,  the 
kits  demonstrate  improved  friendliness  which  is  expected  to  further  improve  over  time. 

Technical  achievements  are  demonstrated  in  the  releases  of  technology  to  the  foundry.  The  current 
customers  have  been  Cadence  customers  and  there  have  been  four  releases  to  the  foundry;  Mayo 
and  the  Sacramento  Air  Logistics  Center  have  released  MCM-C  designs;  Mayo  and  ISI  will  have 
released  MCM-D  designs.  IBM  has  used  the  design  kits  in  the  ASEM  designs  for  Sun  and  the 
known  good  die  SCMs. 
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2.2.6.1  Trademarks 

The  following  are  trademarks,  registered  trademarks,  and  service  marks  of  other  companies  that 
are  used  in  this  document. 

The  following  are  trademarks  of  the  Mentor  Graphics  Corporation;  CheckMate,  Design  Architect, 
FabLink,  FastScan,  FlexTest,  LAYOUT,  LIBRARIAN,  PACKAGE,  SMARTROUTERgrid, 
SMARTROUTERshape,  QuickCheck,  QuickFault  II,  QuickGrade,  QuickPath,  QuickSim, 
QuickSim  II,  SimView,  and  System-1076.  The  following  are  registered  trademarks  of  the  Mentor 
Graphics  Corporation;  Mentor  Graphics  and  AutoTherm. 

The  following  are  trademarks  of  Cadence  Design  Systems,  Inc.  Allegro,  Cadence,  Composer, 
Concept,  GDSII,  LeapFrog,  SKILL,  SigNoise,  ValidPACKAGER,  Verilog-XL,  Veritime,  and 
Viable.  The  following  are  registered  trademarks  of  the  Cadence  Design  Systems,  Inc.; 
DRACULA,  Thermax,  Verifault-XL,  and  Verilog. 

Crosstalk  Toolkit(XTK),  Crosstalk  Field  Solver(XFX),  Crosstalk  Network  Simulator(XNS),  and 
Pre-Route  Delay  Quantifier(PDQ)  are  trademarks  of  Quad  Design. 

Other  brand  or  product  names  that  appear  in  this  document  are  trademarks  or  registered 
trademarks  of  their  respective  holders. 
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2.3  Design  System/F oundry  Interfaces 

pie  objective  of  the  interface  effort  was  to  define  a  multi-level  design  interface  to  the  IBM  foundry 
from  the  Cadence  and  Mentor  Graphics  tool  sets  that  would  minimize  interface  cycle  time  and 
errors.  Design  interfeces  are  the  interfaces  between  design  phases  and  between  tool  sets  used  in 
esign.  They  require  specific  sets  of  information  to  be  exchanged  and  specific  formats  for  the 
information  so  it  can  be  routinely  processed.  The  scope  of  the  interface  effort  was  limited  to 
mainly  support  the  interface  between  completed  physical  design  and  the  foundiy,  but  some  effort 
was  allocated  to  the  logic  to  physical  design  phase,  and  minimal  effort  was  allocated  to  address  the 
specification  interface  to  logic  design.  The  interfaces  were  documented  and  in  some  cases 
information  processors  were  developed  to  reduce  the  cycle  time  through  the  interface.  This 
(Design  System/Foundry  Interfaces)  section  simply  describes  the  interfeces,  the  exercising  of  the 
physical  and  logic  interfaces  is  detailed  in  the  Direct  Release  section  to  demonstrate  their 
successful  definition  and  corresponding  cycle  times.  Demonstration  of  the  specification  interface  is 
supported  by  IBM's  historic  capability  to  create  functional  products.  No  additional  specification 
interface  demonstration  effort  was  deemed  cost  effective  toward  meeting  contract  objectives. 

In  documenting  the  Design  System/Foundry  Interfaces,  effort  was  made  to  incorporate  as  many 
standards  and  pseudo-standards  as  possible.  Standards  and  pseudo-standards  included  Gerber  and 
GDS2  for  artwork,  EDIF  as  part  of  the  logic  interface,  and  VHDL  for  behavioral  specification 
activity.  The  initial  description  of  the  interface  was  made  with  an  effort  to  be  consistent  with  other 
MCM  foundries,  through  joint  activity  with  the  ASEM  Customer  Foundry  Working  Group 
associated  with  the  MCC  ASEM  contract.  The  Design  System/Foundiy  Interfaces  effort  resulted 
m  the  deliverable  titled  "IBM  Foundry  Interface  Specification  CLIN  0002AG”.  Additional  details 
regarding  the  interfaces  can  be  found  in  that  document. 

The  interfaces  described  include: 

•  Completed  physical  design  interface  to  the  foundry 

•  Completed  logic  design  interface  to  the  foundry 

•  Definition  of  the  specification  interface  to  the  foundry 

Since  Cadence  Allegro  is  used  for  original  equipment  manufacturers  (OEM)  MCM  physical  design 
at  the  IBM  foundry,  the  following  combinations  of  tools  and  interfaces  have  been  defined.  The 
logic  and  physical  interfaces  were  exercised  (cases  2  through  6). 


Case 

Logic  Design 

Physical  Design 

Release 

1 

IBM(Mixed) 

IBM(Cadence) 

IBM(intemal) 

2 

Customer(Cadence) 

IBM(Cadence) 

IBM(intemal) 

3 

Customer(MGC) 

IBM(Cadence) 

IBM(intemal) 

4 

Customer(Cadence) 

Customer(Cadence) 

IBM(intemal) 

5 

Customer(MGC) 

Customer(MGC-Gerber) 

IBM(intemal) 

6 

Customer(MGC) 

Customer(MGC-GDS2) 

IBM(intemal) 

2.3.1  Communication  Channels 


Business  contacts  are  established  through  the  marketing  and  sales  organization. 
Preferred  paths  for  exchanging  data  are: 

•  Internet  -  mail,  ftp 
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•  Disks  -  3.5  inch 

Additional  paths  can  be  considered  on  an  individual  basis. 

2.3.2  Specification  Interface 

The  specification  interface  requires  the  foundry  to  complete  detailed  logic  and  physical  design 
(depicted  as  case  1). 


Case 

Logic  Design 

Physical  Design 

Release 

1 

IBM(Cadence) 

The  information  required  includes: 

(note  that  preferences  are  listed  in  order  for  each  environment,  hard-copy  is  an  option  but  is  not 
listed  since  it  can  be  used  to  convey  all  the  information  elements) _ 


Information 

■  —  ■  --  —  -  - 

Mentor  Graphics 
Customer 

Cadence  Customer 

Design  Documentation  and 

Product  Specifications 

ASCII,  Postscript 

ASCII,  Postscript 

Schematic  (with  Symbols) 

EDIF  2  0  0,  Postscript 

Cadence  Files,  EDIF  2  0  0, 
Postscript 

Behavioral  model 

VHDL  1076 

VHDL  1076 

Design  verification  tests 

WAVES,  QuickSim 

WAVES,  Verilog,  RapidSim 

Optional  information  includes: 


Information 

Mentor  Graphics 

Customer 

Cadence  Customer 

Chip  physical  symbols,  timing,  and 
thermal  data 

DIE  format,  ASCII, 
Postscript 

DIE  format,  ASCII, 

Postscript 

This  (specification)  interface  demonstration  is  supported  by  IBM's  historic  capability  to  create 
functional  products.  No  specific  demonstration  effort  was  deemed  cost  effective  toward  meeting 
contract  objectives. 

2.3.3  Logic  Interface 


This  interface  was  defined  for  the  following  cases: 


Case 

Logic  Design 

Physical  Design 

Release 

2 

Customer(Cadence) 

IBM(Cadence) 

IBM(intemal) 

3 

Customer(MGC) 

IBM(Cadence) 

IBM(intemal) 

2-48 


The  following  information  is  needed: 


(note  that  preferences  are  listed  in  order  for  each  environment,  hard-copy  is  an  option  but  is  not 
listed  since  it  can  be  used  to  convey  all  the  information  elements)  _ 


Information 

Cadence  Customer 

Mentor  Graphics 

Customer 

Design  Documentation  and  Product 
Specifications 

ASCII,  Postscript 

ASCII,  Postscript 

Chip  physical  symbols,  timing, 
thermal  data 

DIE  format,  ASCII, 
Postscript 

DIE  format,  ASCII, 

Postscript 

Netlist 

Concept  Native,  Third 

Party,  ASCII 

Cadence  Third  Party,  MGC 
Native,  ASCII,  EDIF  2  0  0 

Layout  constraints 

Netlist  Property,  ASCII,  or 
Schematic 

Netlist  Property,  ASCII,  or 
Schematic 

Optional  information  includes: 


Information 

Cadence  Customer 

Mentor  Graphics 

Customer 

Manufacturing  test  (MCM 
functional  test)  vectors 

Verilog  VCD  file.  Signal 
def.  file 

QuickSim  Log  file.  Signal 
def .  file 

Manufacturing  test  (Chip  internal 
test) 

-  JTAG  ASIC 

ASIC  BIST  Interface 

ASIC  BIST  Interface 

Manufacturing  (MCM  interconnect 
test) 

j  BSDL  (each  ASIC) 

BSDL  (each  ASIC) 

Back  annotation  (Schematic) 

Cadence  Files 

EDIF  2  0  0,  Generic  Netlist 

Back  Annotation  (Delay) 

SDF  (Verilog),  Generic 
(RapidSim) 

ASCII  delay  b.a.  file 
(QuickSim) 

Design  Documentation  and  Product  Specifications  can  be  free  format,  but  a  soft-copy  checklist 
requesting  this  type  of  information  is  also  available  from  the  foundry  and  is  provided  with  available 
design  kits.  Defining  the  checklist  allowed  easier  searching  and  recognition  of  requirements  at  the 

foundry.  This  soft-copy  document  also  reminds  users  to  consider  defining  various  characteristics 
that  their  product  may  want. 

The  development  of  the  DIE  format  for  conveying  chip  information  provides  a  potentially  standard 
format  to  enhance  library  development  and  therefore  significantly  reduce  design  cycle  time  The 
Dffi  format  also  provides  the  electronic  format  capability  that  reduces  opportunities  for  error  by 
eliminating  the  need  to  re-enter  data.  Prior  to  the  DIE  format  development,  the  recommended 

format  was  some  variation  of  ASCII,  again  in  an  effort  to  reduce  data  entry  problems  and  provide 
a  somewhat  processable  format. 

Test  can  be  a  significant  cost  and  cycle  time  aspect  of  a  product,  for  that  reason  care  should  be 
given  to  partition  the  test  effort  effectively  between  the  customer  and  foundry.  Typically  the  test 
tas  partitioning  has  resulted  in  the  foundry  only  doing  some  level  of  interconnect  test  for 
prototypes  but  not  much  functional  test.  When  test  is  part  of  the  program,  effort  should  be  placed 
oninsunng  that  the  version  of  the  test  data  really  corresponds  to  the  version  being  assembled. 

When  module  test  information  needs  to  be  provided,  test  information  can  come  through  the 
standard  formats  supported  by  either  the  Cadence  or  Mentor  Graphics  logic  design  tools. 
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2.3.3.1  Cadence  Customer  -  Logic  Design 

A  customer  using  Cadence  logic  design  tools  would  send  the  native  Cadence  interface  files  to 
initiate  physical  design  since  IBM  uses  the  Cadence  tools.  By  defining  the  IBM-Cadence  interface 
as  the  native  Cadence  tool  interfaces,  not  only  does  forward  data  transfer  become  simple,  back- 
annotation  is  also  maintained  by  'standard'  Cadence  customer  support  activities. 

Secondary  formats  can  be  processed,  such  as  EDIF  2  0  0,  ASCII  files,  but  these  formats  are  less 
preferable  due  to  additional  cycle  time  impact,  hence  cost.  A  discussion  regarding  the  processing 
of  EDIF  can  be  found  in  the  Mentor  Graphics  Customer  -  Logic  Design  section. 

2.3.3.2  Mentor  Graphics  Customer  -  Logic  Design 

A  customer  using  Mentor  Graphics  Corporation  logic  design  tools  would  send  the  native  files  or  an 
EDIF  file  to  initiate  physical  design. 

Two  native  file  paths  are  preferred.  First,  the  Cadence  Third  Party  format  is  identified  as  the 
preferred  format  for  the  netlist  since  Mentor  Graphics  does  support  the  Third  Party  format  from 
Design  Architect.  Second,  since  many  customers  may  not  have  purchased  this  option,  native 
Mentor  Graphics  physical  interface  file  formats  are  also  supported.  The  native  Mentor  Graphics 
physical  interface  files  consist  of  the  'NETS',  'COMPS',  and  'GATES'  files.  These  contain  die 
information  to  create  the  Cadence  Allegro  'Third  Party'  Interface.  With  the  converted  Mentor 
Graphics  native  physical  interface  scenario,  back-annotation  of  pin  numbers  and  reference 
designators  is  obvious  (part  of  the  file  formats). 

EDIF  2  0  0  is  supported  for  die  logic  interface  but  EDIF  adds  significant  complexity  to  the  transfer 
and  does  not  ease  the  back  annotation  issues. 

When  exercising  the  EDIF  data  exchange  path,  non-standard  properties  used  to  convey  standard 
information  had  to  be  resolved.  Significant  effort  was  required  to  scope  the  limitations  of  the 
exchange  capabilities,  entities  such  as  bus  descriptions,  property  mapping  files,  and  even 
representation  size  information  had  to  be  described.  With  the  characteristics  defined,  the  EDIF 
was  handled  through  the  Cadence  EDIF  Interface  facility.  After  the  EDIF  was  converted  to  a 
Cadence  schematic,  it  still  needed  to  be  processed  through  PACKAGER  to  convey  the  physical 
design  information  to  Allegro.  Outputting  data  fromm  PACKAGER  involved  additional  library 
development  work. 

Back-annotation  with  EDIF  requires  a  full  schematic  replacement,  therefore  the  only  way  to 
reverify  the  back  annotation  did  not  change  functionality  is  to  completely  reverify  the  schematic. 

2.3.4  Physical  Interface 

This  interface  was  defined  for  the  following  cases: 


Case 

Physical  Design 

Release 

4 

Customer(Cadence) 

5 

Customer(MGC-Gerber) 

6 

Customer(MGC-GDS2) 

In  general  there  are  some  specifications,  some  logic  information  and  physical  information  needed  to 
adequately  support  MCM  build  through  the  physical  interface. 

The  following  information  is  needed: 

(note  that  preferences  are  listed  in  order  for  each  environment,  hard-copy  is  an  option  but  is  not 
listed  since  it  can  be  used  to  convey  all  the  information  elements) 
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Information 

Cadence  Customer 

Mentor  Graphics  Customer 

Design  Documentation  and  Product 
Specifications 

ASCII,  Postscript 

ASCII,  Postscript 

Netlist 

From  Cadence  .brd  file, 
Third  Party  Netlist 
format 

From  Mentor  Graphics  ‘Neutral’  file, 
(NETS,  COMPS,  GATES),  ASCII 

Chip  physical  symbols 

Cadence  .brd  file, 
Cadence  Symbols 

Converted  from  ‘Neutral’  file 

Shapes  (Artwork)  data 

From  Cadence  .brd  file, 
Gerber 

Gerber  files,  Aperture  Table,  Format 
Description,  Technology  File  (Layer 
cross  reference  table),  GDS2  files 

Optional  information  includes: 


Information 

Cadence  Customer 

Mentor  Graphics  Customer 

Manufacturing  test  (MCM  functional 
test)  vectors 

Verilog  VCD  file. 

Signal  def.  file 

QuickSim  Log  file.  Signal  def .  file 

Manufacturing  test  (Chip  internal  test) 
-JTAGASIC 

ASIC  BIST  Interface 

ASIC  BIST  Interface 

Manufacturing  (MCM  interconnect 
test) 

BSDL  (each  ASIC) 

BSDL  (each  ASIC) 

Back  annotation  (Schematic) 

Cadence  Files 

EDIF  2  0  0,  Generic  Netlist 

Back  Annotation  (Delay) 

SDF  (Verilog),  Generic 
(RapidSim) 

ASCII  delay  b.a.  file  (QuickSim) 

Design  Documentation  and  Product  Specifications  can  be  free  format,  but  a  soft-copy  checklist 
requesting  this  type  of  information  is  also  available  from  the  foundiy  and  is  provided  with  available 
design  kits.  Defining  the  checklist  allowed  easier  searching  and  recognition  of  requirements  at  the 
foundry.  This  soft-copy  document  also  reminds  users  to  consider  defining  various  characteristics 
that  their  product  may  want. 

Test  can  be  a  significant  cost  and  cycle  time  aspect  of  a  product,  for  that  reason  care  should  be 
given  to  partition  the  test  effort  effectively  between  the  customer  and  foundry.  Typically  the  test 
task  has  resulted  in  the  foundry  only  doing  some  level  of  interconnect  test  for  prototypes  but  not 
much  functional  test.  When  test  is  part  of  the  program,  effort  should  be  placed  on  insuring  that  the 
version  of  the  test  data  really  corresponds  to  the  version  being  assembled.  When  module  test 
information  needs  to  be  provided,  test  information  can  come  through  the  standard  formats 
supported  by  either  the  Cadence  or  Mentor  Graphics  logic  design  tools. 

Of  the  two  Mentor  Graphics  Physical  Design  paths,  the  Gerber  path  is  preferred.  Reasons  GDS2 
is  not  preferred  will  be  described  in  more  detail  in  the  Direct  Release  Demonstration  section. 

2.3.4.1  Cadence  Customer  -  Physical  Design 

Early  in  the  IBM/Cadence  company  relationship,  a  converter  was  written  for  the  conversion  of  the 
Cadence  internal  database  format  to  the  IBM  internal  release  format  (GL1).  Since  the 
Cadence/GLl  path  exists,  the  standard  process  for  releasing  physical  designs  to  the  foundry  is  by 
shipping  the  Cadence  board  (.brd)  file. 

The  Cadence  board  file  provides  both  the  physical  and  logic  information  required.  Many  MCM 
designs  have  been  released  to  the  foundry  from  both  internal  IBM  designers  and  OEM  customers 
who  use  Cadence  tools.  In  order  to  identify  potential  problems  earlier  in  the  design  process, 
interim  design  reviews  have  been  described  in  the  design  methodology  recommendations  such  that 
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devices  defined  in  Cadence  symbols  get  reviewed  with  the  foundry  before  releasing  a  completed 
design.  Requests  for  pad  stack  and  symbol  (.dra)  files  have  been  made  to  aid  in  library 
development. 

The  Cadence  Customer  -  Physical  design  interface  has  many  of  the  same  concerns  as  the  logic 
interface  relative  to  the  data  consistency  issues  regarding  module  assembly  and  test.  However,  the 
strict  conversion  of  physical  design  data  occurs  rather  smoothly. 


2.3.4.2  Mentor  Graphics  Customer  -  Physical  Design  GERBER 
Data  included  in  this  interface  is: 


Information 

Mentor  Graphics  Customer 

Netlist 

From  Mentor  Graphics  ‘Neutral’  file,  (NETS,  COMPS, 

GATES),  ASCII 

Chip  physical  symbols 

Converted  from  ‘Neutral’  file 

Shapes  (Artwork)  data 

Gerber  files.  Aperture  Table,  Format  Description,  Technology 
File  (Layer  cross  reference  table) 

The  Gerber  path  is  the  preferred  path  for  physical  design  entry  from  the  Mentor  Graphics  tools. 

The  data  exchange  from  Mentor  Graphics  utilizes  Gerber,  augmented  by  logic  and  device 
information  in  an  ASCII  format.  The  ASCII  format  chosen  is  the  standard  Mentor  Graphics 
'neutral  file'  from  the  FABLINK  tool.  The  'neutral  file'  has  more  information  than  minimally 
required  but  is  easy  to  generate  by  the  customers.  An  alternate  format  that  could  be  equally 
effective  is  a  'Point  file'  as  defined  in  the  MCC  ASEM  Foundry  Interface  Spec.  The  'Point  file' 
format  was  not  the  primary  format  worked  on  because  it  was  not  available  as  a  base  tool  output, 
though  it  could  be  created  from  available  data. 

Gerber  is  used  to  exchange  artwork  information  which  represents  physical  net  location  and 
relationships  to  other  nets.  In  that  sense,  the  exchange  format,  either  Gerber,  is  not  used  as 
originally  intended  as  a  artwork  tool  driver,  but  the  format  is  used  to  exchange  information.  The 
difference  is  that,  in  a  pure  artwork  tool  environment,  it  is  not  particularly  a  concern  whether  a 
shape  is  created  as  a  single  entity  (e.g.  a  flash,  or  shape)  or  whether  it  is  drawn  and  filled  in  with 
lines  or  shapes.  For  data  exchange,  it  is  important  that  each  feature  is  represented  as  a  single 
shape  or  'flash'  of  an  aperture.  Only  lines  are  drawn,  and  those  lines  are  drawn  from  coordinate  to 
coordinate  and  should  begin  at  the  location  of  a  shape  (e.g.  pad  or  via).  The  format  when  used  for 
data  exchange  needs  to  be  able  to  represent  the  characteristics  of  the  technology  (e.g.  only  circles, 
rectangles  and  lines,  or  only  polygon  pads  and  circular  vias  etc.) 

When  Gerber  is  the  transfer  format,  it  is  imported  to  Cadence  Allegro  for  conversion  to  the  IBM 
internal  format.  The  internal  format  data  is  processed  against  manufacturability  checks  (using 
MDS)  prior  to  release  to  the  factory. 

The  'neutral  file'  data  is  used  to  verify  logical  to  physical  implementation  in  the  foundry  internal 
data  format.  The  data  is  manipulated  to  recreate  the  device  information,  placement  information, 
and  netlist  information,  all  in  a  format  that  is  processable  at  IBM.  The  IBM  processable  data 
format  is  used  to  create  the  data  for  substrate  opens  and  shorts  test,  and  supports  manufacturing 
assembly  and  documentation  requirements.  An  automated  program  'MgcToCad'  was  created  to 
support  the  ‘neutral  file’  data  conversion. 
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The  Mentor  Graphics  Customer  -  Physical  Design  Gerber  interface  has  many  of  the  same  concerns 
as  the  logic  interface  relative  to  the  data  consistency  issues  regarding  module  assembly  and  test. 
However,  the  strict  conversion  of  physical  design  data  occurs  rather  smoothly. 

2.3.4.3  Mentor  Graphics  Customer  -  Physical  Design  GDS2 


Data  included  in  this  interface  is: 


Information 

Mentor  Graphics  Customer 

Netlist 

From  Mentor  Graphics  ‘Neutral’  file,  (NETS,  COMPS, 
GATES),  ASCII 

Chip  physical  symbols 

Converted  from  ‘Neutral’  file 

Shapes  (Artwork)  data 

GDS2  files.  Technology  File  (Layer  cross  reference  table) 

With  the  exception  of  the  artwork  processing  the  GDS2  path  is  very  similar  to  the  Gerber  path.  For 
processing  the  artwork,  there  is  a  stand  alone  program  used  to  convert  GDS2  into  the  IBM  internal 
format.  The  internal  format  data  is  processed  against  manufacturability  checks  prior  to  release  to 
the  factory.  Much  more  editing  of  the  data  is  required  to  process  GDS2  data  so  it  is  not  the 
recommended  path. 

Mentor  Graphics  Customer  -  Physical  Design  GDS2  interface  has  many  of  the  same  concerns  as 
the  logic  interface  relative  to  the  data  consistency  issues  regarding  module  assembly  and  test.  The 
strict  conversion  of  physical  design  data  is  generally  more  difficult  than  the  Gerber  path. 

2.3.5  Conclusions 

Interfaces  have  been  defined  to  support  multiple  design  level  interfaces  to  the  foundry. 

Well  defined  interfaces  have  improved  communications  with  OEM  customers.  Many  are  willing  to 
provide  information  in  requested  formats.  For  those  that  have  special  needs  that  require 
submission  of  information  in  formats  other  than  those  described,  it  is  known  at  the  beginning  of  the 
relationship  that  additional  processing  effort  will  be  required.  Continued  foundry  maintenance  of 
these  interfaces  is  necessary  as  industry  and  technology  changes  occur. 
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2.4  Direct  Release 

IBM  had  developed  a  release  system  strongly  directed  towards  the  standard  module  families  used 
by  many  of  the  internal  IBM  product  lines  that  the  foundry  traditionally  supported.  The  IBM 
internal  release  process  focused  on  quick  release  of  routing  interconnect  layers  that  were 
compatible  with  pre-designed  redistribution  and  power  layers  for  a  given  chip  set  and  package 
definition. 

This  existing  release  system  was  not  suited  to  handle  the  custom  MCM’s  typically  required  in  the 
merchant  market.  Custom  MCM's  require  that  all  layers  of  an  MCM  be  designed  and  released 
concurrently.  In  addition,  specifications  and  drawings  are  generated  concurrently  with  the  design 
so  traditional  work  sequencing  that  was  incorporated  into  the  standard  module  family  release 
process  appeared  as  product  delays  and  bureaucracy  in  the  custom  MCM  environment.  For  this 
reason  contract  activity  was  defined  to  enhance  the  release  process  to  meet  the  ASEM  goals  of 
providing  low  volume  access  to  a  high  volume  foundry,  reducing  cycle  times  and  NRE,  and 
routinely  achieving  first  pass  success  on  designs. 

2.4.1  Introduction 

Some  common  terminology  will  be  described  since  it  will  be  used  throughout  this  report. 

Multichip  Module  (MCM)  layers  can  be  categorized  into  three  types;  redistribution  (chip  to 
substrate  grid  translations),  power-and-reference,  and  personality  (signal  netlist  interconnections). 
Redistribution  and  power-and-reference  layers  can  be  referred  to  as  “fixed”  layers  because  they 
don’t  have  to  change  if  the  netlist  changes.  Personality  layers  contain  signal  interconnections, 
which  represent  the  personality’  of  a  module,  hence  its  name.  Any  layer  that  interconnects  net 
terminals  is  called  a  personality  layer,  regardless  of  any  power  or  redistribution  functions  also 
occurring  there. 

Standard-module-families  versus  custom  MCMs  also  needs  to  be  defined.  Custom  MCMs  are 
defined  to  be  MCMs  that  are  unique  to  a  single  application.  A  standard-module-family  (MCM- 
family)  is  group  of  applications  that  utilize  a  common  chip  set.  Some  other  features  of  a  MCM- 
femily  are  a  common  device  placement,  common  power  I/O  assignment,  and  common  signal  I/O 
availability  (I/O  to  chip  set  connections  are  not  predefined  just  the  number  and  locations  of  signal 
I/O).  Note  that  if  the  chip  set  included  a  number  of  ASICs  or  FPGAs,  the  foot  prints  can  be  the 
same  even  when  the  function  is  vastly  different.  Within  a  MCM-family,  the  module  ‘personality’ 
layers  are  the  layers  that  make  a  module  unique  to  a  specific  application.  IBM  has  used  MCM- 
femilies  to  support  many  internal  product  development  efforts.  The  IBM  OEM  business  tends  to 
be  custom  in  nature  because  of  the  variation  in  customer  requirements  and  design  philosophies. 

Since  single  chip  modules  (SCMs)  are  a  special  case  of  custom  MCMs,  their  release  will  also  be 
described  in  this  document. 

Prototypes  are  built  for  product  verification  activities,  are  limited  in  number,  and  are  not  generally 
end-user  shippable.  Production  modules  are  made  in  quantity  for  end-user  deliveries.  This 
distinction  is  made  to  allow  different  release  criteria  for  prototype  versus  production  modules, 
which  intentionally  reduces  the  cycle  time  for  development  of  prototypes. 

In  this  report,  the  term  manufacturing  represents  substrate  build,  substrate  test,  module  assembly, 
and  module  test.  A  customer  can  request  products  with  any  or  all  of  these  items. 

The  release  process  is  the  interface  between  development  (design)  and  manufacturing.  Therefore 
the  major  objective  of  a  release  system  is  to  support: 


2-55 


Documentation  development  and  management 
Data  verification 

Data  transformation  to  manufacturing  tools/data  (masks,  etc.) 

2.4.2  Architecture  and  Objectives 

The  Corporate  Release  Processing  System  (CRPS)  developed  for  IBM’s  internal  standard  module 
family  release  requirements  had  been  very  effective  at  helping  IBM  achieve  it's  world  class  product 
deliveiy  capabilities.  For  that  reason  it  was  seen  as  a  proper  starting  point  for  defining  typical 
capabilities  and  objectives. 

When  initiating  release  of  a  new  member  of  an  MCM  family  in  IBM,  functional  requirements  are 
defined  in  a  single  data  container  called  a  Release  Interface  Transmittal  (RIT).  By  definition,  the 
ideal  of  a  single  container  allows  management  of  data  integrity  because  all  needed  information 
resides  or  is  referenced  from  the  single  data  container.  With  a  single  data  container,  various  checks 
can  also  be  run  to  verify  that  all  expected  information  was  available  and  to  some  extent  proper 
(e.g.  a  correct  format).  More  information  was  needed  to  describe  a  custom  MCM  than  what  was 
currently  supported  with  a  RIT.  For  this  reason  an  extended  Release  Interface  Transmittal 
(XRIT)  definition  was  to  be  used.1  The  ASEM  defined  XRIT  was  to  be  much  more  complete. 

This  type  of  a  single  repository  system  was  defined  in  the  “ASEM  Report  on  Architecture”;  Direct 
Release  Architecture  Document,  CLIN  0002AJ. 

XRIT  expansion  came  from  defining  and  adding  parameters  beyond  existing  XRIT  and  RIT 
parameters  to  handle  requirements  for  the  redistribution,  power/reference  layers,  and  the  increasing 
number  of  mixed  layer  types.  Effort  was  also  placed  on  defining  improved  user  interfaces  to 
existing  parameters  needed  for  personality  layers.  Included,  also,  was  definition  of  manufacturing 
documentation  automation  (part  number  assignment,  bill  of  material  generation,  etc.) 

Studies  were  made  on  what  types  of  data  integrity  checks  could  be  possible.  This  included  logical 
to  physical  re-verification,  data  format  and  syntax  checking,  time-date  stamp  items. 

2.4.3  Implementation 

The  results  of  these  studies  showed  what  needed  to  be  done,  the  next  problem  was  to  determine 
how  to  implement  the  requirements  into  an  effective  system.  Two  approaches  were  available, 
extend  the  existing  release  system  to  cover  the  new  requirements  or  incrementally  integrating  the 
manual  paths  in  a  way  that  prototype  capabilities  could  be  tested,  then  utilized  as  they  were 
developed. 

2.4.3.1  Strategy 

The  approach  taken  was  to  insure  success  of  the  implementation  by  incrementally  prototyping  the 
integration  and  automation  efforts.  This  turned  out  to  be  very  successful,  the  team  that 
implemented  this  was  a  combination  of  users  and  programmers  that  worked  out  operational  issues 


Original  IBM  XRITs  focused  on  improving  standard  module  family  rule  generation  and  data  integrity  verification, 
the  ASEM  use  of  XRITs  for  custom  MCMs  was  to  eliminate  rule  generation  since  processing  would  be  'one  shot' 
only 
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and  tested  individual  features  as  early  as  possible.  Along  with  the  prototyping  efforts,  a  concurrent 
look  at  errors  was  continued  in  weekly  meetings.  The  weekly  meetings  gave  focus  to  the  most 
critical  aspects  of  release  and  insured  that  efforts  were  directed  to  solving  the  worst  problems  first. 

2A.3.2  Methods  and  processes  within  the  System 

This  section  summarizes  the  information  described  in  deliverable  “ASEM  Report  on  Methodology 
&  Process  within  the  Release  System”  Document  Number  CLIN  0002AK. 

2.4.3.2.1  IBM  Module  Release  Overview 

In  the  packaged  electronics  development  environment,  a  typical  process  to  build  an  MCM  product 
consists  of  three  phases  which  can  overlap:  design,  release,  and  manufacturing.  In  the  ISO9001 
registered  IBM  Foundry,  these  phases  are  part  of  the  overall  ‘E.Fishkill  Packaging  Development 
Checkpoint  Process’  that  has  been  developed  to  assure  timely  and  systematic  execution  of  new 
product  development  activity.  This  Checkpoint  Process  requires  each  new  product  to  have  a 
unique  ‘Document  of  Execution  (DOE)’  written  to  describe  what  aspects  of  the  general  process  are 
needed  for  this  specific  customer.  The  DOE  also  identifies  responsible  organizations  that  will 
generate  the  release  information,  line  control  requirements,  key  dates,  and  other  program 
information.  This  report  will  describe  the  release  methodology  and  processes  that  are  used  to 
satisfy  the  product  requirements  defined  in  the  DOE. 

Organizational  Responsibility 

Per  the  ‘E.Fishkill  Packaging  Development  Checkpoint  Process’,  Product  Engineering  is 
responsible  for  most  release  activity  however  Design  Engineering  has  a  large  supporting  role. 

Design  Engineering  is  responsible  for  creating  and  preparing  for  review  all  computer  aided  design 
(CAD)  data,  whether  submitted  by  the  customer  or  generated  by  the  design  organization.  In  the 
preparation  for  review,  manufacturability  verification  (e.g.  Design  Rule  Checking)  and  any 
additions  or  modifications  (e.g.  mask  support  mesh)  is  done  to  support  manufacturing.  The 
verification  also  insures  that  data  needed  to  support  substrate  build  and  test  are  in  acceptable 
formats  for  processing.  Any  changes  required  to  the  customers  data  are,  of  course,  reviewed  with 
them  first.  Documentation  is  created  describing  the  design  data  and  a  review  is  held.  Given 
completion  of  the  review.  Design  Engineering  stores  all  its  data  on  a  secure  database  and  provides 
Product  Engineering  with  the  data,  thus  completing  its  responsibilities.  An  additional  special 
function  of  Design  Engineering  is  to  create  rules  for  customers  designing  members  of  MCM- 
families  in  file  IBM  Engineering  Design  System  (EDS)  and  to  release  them  through  the  automated 
release  process  described  later. 

Documentation  development,  data  transformation,  and  rest  of  the  data  verification  (e.g.  module 
assembly  and  test)  responsibilities  belong  to  Product  Engineering.  This  will  be  described  more 
completely  below.  Except  where  noted.  Product  Engineering  will  be  performing  the  items 
described. 

Release  System  Functions  And  Cycle 

Release  activities  overlap  design  and  manufacturing  processes  to  minimize  product  cycle  times  by 
beginning  the  manufacturing  phase  as  soon  as  information  is  available  for  the  initial  build  steps. 

The  critical  path  consists  of  design,  some  elements  of  release,  and  manufacturing.  In  the  Custom 
MCM/SCM  and  MCM-family  release  sections,  these  critical  path  items  will  be  highlighted. 

Release  functions  will  be  generally  described  next  and  are  identified  globally  as: 

Documentation  development  and  management 
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Data  verification 

Data  transformation  to  manufacturing  tools/data 

Documentation  development  and  management 

The  objective  of  documentation  development  and  management  is  to  assure  that  data  is  available, 
distributable,  and  properly  stored.  This  includes  data  backup  and  recovery  requirements. 

Product  documentation,  which  consists  of  business  data,  bills  of  materials  (BOMs),  specifications 
(including  process  definition  and  routings),  and  mechanical  drawings  that  describe  the  product,  is 
managed  based  on  the  program  requirements  defined  in  the  DOE. 

In  the  Release  process,  unique  identifiers  (e.g.  part  numbers)  get  added  to  sets  of  product 
information  and  manufacturing  process  information  to  create  the  product  documentation  which  is 
the  recipe  to  build  what  the  customer  needs.  Product  Engineering  is  responsible  to  compile  the 
documentation  requirements  from  information  created  by  Applications  Engineering  (with  the 
Customer)  and  Design  Engineering.  Product  Engineering  makes  sure  that  this  data  satisfies  the 
product  and  manufacturing  requirements. 

For  production  modules  the  DOE  will  define  completion  of  all  phases  of  the  checkpoint  process. 
Part  of  that  completion  is  that  documentation  must  conform  to  format  and  review  requirements  as 
described  in  ‘Pre-Analysis/Implementation  of  Engineering  Changes  Process  (OP45)’.  OP45  is  a 
site  operating  procedure  used  to  insure  EC  control  of  manufacturing  product  data.  Product 
documentation  is  originally  compiled  on  ‘Product  Engineering  Worksheets’  and  then  transferred  to 
formal  documentation  formats.  Manufacturing  Work  requests  (MWR)s  are  used  to  describe 
processes  for  manufacturing  products.  These  are  created  manually  for  new  MCM-families  and 
custom  production  MCMs.  Routings  are  also  manually  established  in  the  Factory  Integrated 
Routing  System  (FIRS)  system  which  directs  operation  on  the  manufacturing  floor.  All  data  is 
reviewed  and  approved  within  the  formal  OP45  process.  Production  module  documentation  is 
stored  with  the  product  engineer  until  OP45  is  complete.  When  OP45  is  complete,  all  the  product 
documentation  can  be  found  via  the  Development  &  Production  Records  System  (DPRS).  While 
referenced  from  DPRS,  drawing  information  is  kept  in  the  CATIA  Data  Manager  (CDM)  data 
base.  CDM  and  DPRS  have  the  necessary  controls  for  data  management  and  recovery. 

For  prototypes,  the  DOE  does  not  generally  require  completion  of  all  the  phases  of  the  checkpoint 
process.  Therefore  documentation  does  not  have  to  conform  to  OP45  requirements  like  production 
modules.  Engineering  Work  requests  (EWR)s  are  used  for  process  definition  and  routing  of 
prototypes  and  engineering  projects.  Memos  and  product  descriptions  are  used  for  specifications 
and  bills  of  materials  (BOMs).  The  EWRs  and  BOMs  are  manually  created  by  product  engineers 
as  the  data  becomes  available  from  Applications  and  Design  Engineering.  Prototype 
documentation  is  stored  by  the  product  engineer  or  program  manager  per  DOE  requirements. 

The  Prototype  and  Production  Module  documentation  approach  is  summarized  in  Figure  2.4-1. 
Product  documentation  is  distributed  to  the  appropriate  members  of  the  product  management  team, 
defined  in  the  DOE,  and  design  review  meeting  members. 
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Figure  2.4-1:  Release  Documentation  Approach 

CAD  data  (not  mechanical  drawings),  though  not  treated  the  same  as  plain  documentation,  also 


needs  handling  for  storage  and  availability.  It  is  created  as  part  of  the  design  process  either  at  the 
foundry  or  at  the  customer  location.  CAD  data  is  released  to  manufacturing  and  made  available  to 
the  Data  Transformation  functions.  CAD  Data  is  stored  in  its  processable  data  format,  Graphics 
or  Network  Language  One  (GL1  or  NL1),  in  a  database  used  by  manufacturing  called  Integrated 
Storage  Management  (ISM).  This  is  a  responsibility  of  the  Design  Engineering  organization.  Data 
conversion  controls  (e.g.  to  masks,  vias)  and  the  converted  data,  created  by  Product  Engineering,  is 
also  stored  there.  A  detailed  list  of  files  on  ISM  is  described  later.  ISM  has  all  the  necessary 
controls  for  data  management  and  recovery. 

Data  verification 

The  objective  of  data  verification  activities  is  to  verify  consistency  of  data  to  manufacturing 
requirements  (e.g.  design  rules),  to  verify  the  consistency  of  data  within  itself  (e.g.  design  data  and 
test  data),  and  to  verify  the  consistency  of  data  formats  to  processing  requirements. 

Data  verification  for  both  custom  MCMs  and  new  MCM-families  is  done  by  processing  CAD  data 
through  the  ‘Module  Design  System  (MDS)’,  through  checklist  completion,  and  through 
design/product  reviews. 

Design  Engineering  is  responsible  for  substrate  (including  thin  films)  CAD  data  verification. 
Regardless  of  the  design  data  format  received  (Gerber,  GDS2,  ASCII,  etc.),  design  data  is 
converted  to  the  IBM  format  NL1  and  is  verified  against  manufacturability  requirements.  MDS  is 
used  to  check  the  design  rules,  verify  logical/physical  equivalency,  and  assure  data  is  properly 
formatted  for  the  post  processors.  Design  rules  (spacing,  width,  and  grid  verification)  are  checked 
on  individual  layers  and  ‘Z’  direction  ground  rules  are  checked  from  layer  to  layer.  A  continuity 
check  is  done  by  establishing  nets  out  of  features  that  touch  according  to  data  convention  rules 
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(layer  and  adjacent  layer  rules).  The  resulting  netlist  can  be  compared  with  a  user  supplied  netlist 
to  assure  that  processed  data  is  logically  equivalent  to  the  customers  original  intent.  In  doing  these 
checks,  design  data  format  (NL1)  conventions  are  verified  to  insure  the  data  will  be  post 
processable.  MDS  creates  a  Module  Control  File  (MCF)  which  is  used  in  opens/shorts  test  data 
creation  and  rules  generation  for  MCM-families. 


Substrate  build  and  test  information  is  generated  from  this  verified  design  data  thus  insuring  that 
data  is  consistent  with  the  design  intent.  The  data  flow  is  shown  in  Figure  2.4-2. 
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Figure  2.4-2:  CAD  Data  Verification 


Checklists  and  reviews  are  used  to  verify  data  consistency  when  tool  data  is  not  generated  from  the 
design  database  (e.g.  MCM  assembly  and  test).  Additionally,  checklists  (also  known  as 
worksheets)  are  used  in  the  review  process  to  insure  that  all  the  necessary  checking  and 
documentation  of  the  design  data  has  been  done  thereby  ensuring  that  each  function  will  have  the 
data  needed  to  support  the  customer’s  product  requirements. 


Finally,  after  CAD  data  verification  and  the  checklists  are  complete,  design  reviews  are  held  so  all 
key  people  can  review  the  findings  and  approve  release  of  the  design  to  manufacturing.  Function 
approvals  (sign  off)  at  the  reviews  and  meeting  minutes  describe  the  findings  of  these  reviews. 

Any  issues  discovered  in  the  verification  process  are  discussed  with  the  customer  or  the 
appropriate  IBM  personnel  such  that  answers  are  available  during  the  final  review  meeting.  All 
information  required  for  build  is  reviewed  with  the  proper  organizations. 


Data  verification  for  new  members  of  existing  MCM-families  is  handled  completely  within  the 
release  tool  described  in  the  MCM-family  section  later  in  this  report. 
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Data  transformation  to  manufacturing  tools/data  (masks,  eta) 

The  objective  of  data  transformations  is  to  convert  stored  design  data  (GL1  or  NL1)  into  data  that 
allows  required  tools  (masks  etc.)  to  be  built  and  into  data  that  will  direct  the  tools  (numerical 
control  ‘NC’  data).  Figure  2.4-3  shows  the  technology/tool  requirements  for  feature  definition. 
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Figure  2.4-3:  Technology  feature  definition  approach 


Design  data  transformation  occurs  through  Post  Processors  used  in  automatic  and/or  manual  mode. 
The  post  processors  require  parameter  definition  to  convert  the  GL1  or  NL1  data  into  data  for  the 
appropriate  tool  set.  As  part  of  this  process,  part  numbers  are  assigned  so  that  converted  data  can 
be  referenced  from  the  EWR/MWR/Routing  documents  previously  described.  Most  custom 
MCMs  and  first  MCM-family  members  are  processed  in  manual  mode  because  the  parameters 
have  not  been  previously  established  as  is  necessary  for  an  automatic  run.  Therefore  it  is  more 
convenient,  more  versatile,  and  faster  to  run  the  post  processors  as  the  parameters  are  defined. 
Cycle  time  and  error  reduction  activity  is  focused  on  improving  the  user  interfaces  to  ease  design 
data  and  parameter  entry  and  to  assist  in  run  verification  activity.  The  only  true  automatic  release 
runs  are  for  additional  members  of  existing  MCM-families  where  the  parameters  have  been 
predefined  and  verified.  Detailed  flows  will  be  shown  at  appropriate  places  later  in  this  report. 

In  automatic  release  runs,  for  production  MCM-family  members,  the  post  processors  and  test  data 
are  automatically  initiated,  part  numbers  are  automatically  assigned  as  necessary,  bills  of  materials 
are  created  and  loaded  to  DPRS,  and  routings  are  automatically  loaded  to  FIRS. 

Custom  MCM/SCM  Release  Paths 

This  section  will  show  specific  data  flows  and  tools  used  for  custom  MCM  releases  given  the 
prototype  and  production  scenarios  described  in  the  previous  overview  section.  Critical  path  items 
will  identified  and  described  along  with  other  details  unique  to  the  scenario  being  described. 

As  previously  stated,  SCMs  are  processed  as  defined  in  this  section,  so  wherever  MCM  is 
mentioned  it  can  be  interpreted  by  the  reader  to  also  mean  SCM. 

The  documentation  process  is  the  same  for  MCM-C  and  MCM-D  custom  MCMs.  Module  level 
data  verification  is  the  same  for  MCM-C  and  MCM-D.  Substrate  data  verification  is  unique  due 
to  the  MCM-C  versus  MCM-D  mask  differences  and  will  be  described.  Data  transformation  is 
unique,  again  due  to  tool  choices  (reference  Figure  2.4-3). 

MCM-D  Release 

MCM-D  critical  path  items  are  design,  CAD  data  verification  including  mask  data  preparation, 
mask  data  transformation,  and  mask  availability. 

Documentation  is  developed  as  described  in  the  overview  section. 

Critical  path  documentation  includes  the  NL1  summary  sheets,  plots.  Mask  order  information,  and 
Laser  Mask  control  cards  as  is  shown  in  Figure  2.4-4. 

Errors  are  minimized  by  clear  ownership  of  the  current  documentation. 
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Data  verification 

MDS  is  used  for  CAD  data  verification  as  described  earlier  in  the  overview  section.  Feature 
widths  and  spacings,  via  stacking,  large  shape  characteristics,  and  mask  partitioning  are  critical  to 
manufacturability.  Grids,  which  are  important  in  MCM-C  are  much  less  important  here. 

An  additional  MCM-D  data  preparation  and  verification  activity  is  the  partitioning  of  design  data 
into  mask  segments.  This  is  required  for  designs  where  the  MCM  is  larger  that  the  tool  processing 
fields.  Verification  is  achieved  by  reconstructing  a  full  layer  from  the  pieces  and  comparing  with 
the  original  full  field  layer  design  data. 

Substrate  verification  is  part  of  the  critical  path  therefore  substrate  verification  cycle  time 
reductions  directly  affect  product  cycle  times. 

Module  level  data  verification  is  handled  the  same  for  both  MCM-D  and  MCM-C,  through 
checklist  completion  and  product  reviews. 

Data  transformation  to  manufacturing  tools/data  (masks,  eta) 

As  shown  in  the  overview,  data  transformation  occurs  to  create  via  masks,  pattern  masks,  and 
opens/short  test  data.  Mask  data  is  processed  with  the  Pelican  post  processor.  Test  data  is  created 
from  the  MCF  created  by  MDS.  The  Mask  Order  Processing  System  is  an  automated  interface  for 
ordering  and  post  processing  data  for  expose  masks.  Currently  laser  mask  release  occurs  through 
text  editors  and  batch  job  submission. 


Data  integrity  checks  include  return  code  validation  and  run  log  message  verification. 
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MCM-C  Release 

MCM-C  critical  path  items  are  dependent  on  the  tooling  chosen  for  build.  The  tooling  choices  are 
dependent  on  product  requirements  and  business  expectations.  Production  modules  are  always 
created  with  the  standard  MCM-C  tooling.  Prototypes  can  be  created  using  either  the  standard 
tooling  or  Prototype  (E-BEAM)  tooling  for  creation  of  the  substrate  layers.  Tooling  choices  exist 
at  both  the  substrate  and  module  assembly  levels.  Typically  prototypes  tooling  is  chosen  to 
expedite  delivery  to  customers  who  use  the  prototypes  in  their  product  development  activities. 
Critical  path  flows  will  be  shown  in  their  respective  sections. 

Documentation  is  developed  as  described  in  the  overview  section. 

Critical  path  flows  will  be  shown  in  the  Standard  and  Prototype  MCM-C  tooling  sections. 

Errors  are  minimized  by  clear  ownership  of  the  current  documentation. 

Data  verification 

CAD  data  verification  is  processed  through  MDS  as  done  with  MCM-D,  excluding  the 
partitioning/verification  for  masks  since  MCM-C  is  always  full  field.  Grid  characterization  of  the 
pattern  is  important  for  Standard  tooling  MCMs  since  the  grid  and  pattern  affect  mask  creation 
choices.  This  information  is  noted  on  plots  that  proceed  to  the  data  transformation  processes. 

Module  level  data  verification  is  also  handled  the  same  for  MCM-C  and  MCM-D,  through 
checklist  completion  and  product  reviews. 
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Standard  Tooling  MCM-C  release  is  shown  in  Figure  2.4-5  after  the  point  of  CAD  data 
conversion  to  NL1 .  Critical  path  items  are  design,  CAD  Data  verification,  *Summary  Sheets, 
*Marked  up  Plots,  *GLP  Sheets,  Control  Cards,  Post  Processing,  *Mask  Orders  (EWRs),  and 
Mask  Delivery.  The  documentation  aspects  are  identified  with  an  asterisk  (*). 

Automated  interfaces  have  improved  data  entry  and  processing  of  the  design  data  reducing  both 
cycle  time  and  errors  in  the  creation  of  Control  Cards  and  Post  Processing. 

Data  integrity  checks  include  return  code  validation  and  run  log  message  verification. 


Build 


Figure  2.4-6:  Prototype  Tooling  MCM-C  Release _ 

Data  transformation:  Prototype  Tooling  MCM-C  Release 

Prototype  Tooling  (E-BEAM)  MCM-C  release  is  shown  in  Figure  2.4-6  after  the  point  of  CAD 
data  conversion  to  NL1 .  Critical  path  items  are  design,  CAD  Data  verification,  *Summary  Sheets, 
*Marked  up  Plots,  Control  Cards,  and  Post  Processing.  The  documentation  aspects  are  identified 
with  an  asterisk  (*). 

Data  integrity  checks  include  return  code  validation  and  run  log  message  verification. 

Cycle  time  is  shorter  due  to  the  elimination  of  mask  generation. 

Release  for  IBM  MCM-Familv 

Release  for  IBM  MCM-families  is  specific  to  IBM  so  it  will  not  be  summarized  in  this  report.  See 
the  complete  “ASEM  Report  on  Methodology  &  Process  within  the  Release  System”  CLIN 
0002AK  for  those  details. 

ISM  Data  Repository  Detail 

As  previously  mentioned,  manufacturing  relies  on  the  ISM  Database  to  control  and  store  design 
data  and  critical  data  created  during  release.  The  types  of  data  managed  are  as  follows: 
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Design  data 


FG:  GL/1  data,  MCM-family  personality  data  is  stored  as  GL1 . 

FN :  NL/ 1  data,  Custom  MCM/SCM  layer  data  is  stored  as  NL 1 . 

XR(IT):  extended  Release  Interface  Transmittal  which  contains  the  design  converted  to  a 

new  format  (Used  with  MCM  Families) 


NC  data 
Artwork 

FC:  Fixed  Layer  module  Graphics  Language  Processor  for  Gerber  artwork  (GLPG) 

control  information 

(K)AR:  MCM-family  (Personality)  Vias  Inspection  artwork  control  cards 

( )AR:  Other  artwork  data  for  special  case  masks  (e.g.  vias  only,  top  surface  screening) 

(Q)AR:  Q-levels  Layer  (mask  pattern)  artwork  control  cards 

(T)AR:  Support  tabs  for  metal  ‘Q’  masks 


Punch  tools 

QC:  Fixed  Layer  control  cards  to  drive  programmable  via  punch 

PV:  Fixed  Layer  NC  data  for  programmable  via  punch  tool 

Inspection  tools 

IF:  Auto  inspection  data  associated  with  ORBOT 

FO:  ORBOT  screening  mask  inspection  data 

OR:  Control  cards(Fixed  Layer)  for  auto  inspection  (ORBOT). 

OC:  Control  cards(Personality)  for  ovation  data. 

OS:  Test  data 

Manufacturing  rules 

MF :  Fixed  Layer  input  to  post  processors  which  create  FIRS  transactions 

AF:  FIRS  data  for  Fixed  Layer  personality  artwork  layers 

The  ISM  database  manager  controls  the  storage  and  retention  of  design  and  NC  data,  as  well  as 
read,  write,  and  list  access  to  this  data. 
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2.4.4  Demonstration 


Release  of  designs  through  the  IBM  foundry  has  been  demonstrated  for  the  logic  and  physical 
design  entry  paths  and  for  both  prototype  and  manufacturing  volume  product  situations.  This 
section  of  the  report  describes  the  demonstration.  The  full  report  is  contract  deliverable  “Report  on 
Release  System  Demonstration”  CLIN  0002AL. 

This  section  is  further  subdivided  into  sections  on: 

•  Foundry  Interfaces  and  Validation  -  This  sub-section  describes  release  of  designs  through  the 
logic  and  physical  design  entry  interfeces  described  in  the  Design  System/Foundry  Interface 
section  (section  2.3)  of  this  report.  The  details  in  this  section  describe  the  processing  of  design 
data  to  create  and  validate  physical  design  data,  and  to  release  documentation  and  test 
requirements.  The  general  methodology  and  process  of  release  have  previously  been  defined  in 
the  deliverable  “ASEM  Report  on  Methodology  &  Process  within  the  Release  System”  CLIN 
0002AK. 

Design  data  transformation  will  be  specifically  addressed  in  the  second  sub-section  on 
Manufacturing  Tools  Release  Paths  and  Validation. 

•  Manufacturing  Tools  Release  Paths  and  Validation  -  This  section  refers  to  release  activities 
that  are  a  function  of  the  manufacturing  tooling  used  to  fabricate  the  MCM.  It  specifically 
covers  transformation  of  design  data  into  tool  data. 

•  Conclusions  -  This  section  nets  out  conclusions  gained  in  demonstrating  the  Release 
capabilities. 


2.4.4.1  Foundry  Interfaces  and  Validation 
The  interfaces  that  have  been  demonstrated  are: 


Case 

Logic  Design 

Physical  Design 

Release 

2 

Customer(Cadence) 

IBM(Cadence) 

IBM(Intemal) 

3 

Customer(MGC) 

IBM(Cadence) 

IBM(Intemal) 

4 

Customer(Cadence) 

Customer(Cadence) 

DBM(Intemal) 

5 

Customer(MGC) 

Customer(MGC-Gerber) 

IBM(Intemal) 

6 

Customer(MGC) 

Customer(MGC-GDS2) 

IBM(Intemal) 

Regardless  of  the  path  taken,  a  Document  of  Execution  is  written  describing  the  activities  required 
for  releasing  a  new  product  through  the  ISO9001  “E.  Fishkill  Packaging  Development  Checkpoint 
Process”.  This  Checkpoint  Process  requires  each  new  product  to  have  a  unique  ‘Document  of 
Execution  (DOE)’  written  to  describe  what  aspects  of  the  general  process  are  needed  for  this 
specific  customer.  The  DOE  also  identifies  responsible  organizations  that  will  generate  the  release 
information,  line  control  requirements,  key  dates,  and  other  program  information  as  described  in 
the  “ASEM  Report  on  Methodology  &  Process  within  the  Release  System”  CLIN  0002AK. 

The  DOE  gets  developed  through  a  series  of  iterations  with  the  customer  as  their  requirements  are 
described  and  solutions  proposed.  These  requirements  get  converted  into  appropriate 
documentation  to  drive  manufacturing  to  provide  hardware  that  will  meet  customer  needs. 

Logic  entry  into  the  foundry  requires  the  foundry  to  complete  the  physical  design.  In  the  physical 
entry  paths,  the  customer  has  completed  the  physical  design.  Between  the  two  paths,  the  equivalent 
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data  needs  to  be  generated,  verified,  reviewed,  and  released.  Therefore  there  are  many  similarities 
in  the  data  that  is  required  and  processed.  Differences  are  generally  the  result  of  formats  available 
from  specific  tool  sets  and  process  differences  to  accommodate  different  source  tool  capabilities. 

In  both  logic  and  physical  entry  paths,  improvements  in  the  data  conversion  paths  from  the 
commercial  design  systems  into  the  IBM  internal  design  data  formats  have  significantly  reduced 
cycle  time.  The  data  conversion  processes  are  optimized  by  using  design  kit  recommended 
conventions.  The  conventions  include  for  example  instantiation  of  I/O  pads  within  a  separate 
symbol  or  component  and  definition  of  apertures  for  each  pad  type  so  that  features  in  Gerber  (other 
than  lines)  are  flashed  and  not  drawn.  Experience  with  the  Cadence  tools  has  minimized  the 
creation  of  duplicate  features  in  the  Cadence  data  base.  Previously  these  duplicate  features  were 
removed  after  the  conversion  process. 

Cycle  time  has  also  been  reduced  by  optimizing  the  documentation  requirements  into  informal  and 
formal  formats  depending  on  application  requirements  as  described  in  the  ‘E.Fishkill  Packaging 
Development  Checkpoint  Process’. 

Cycle  time  and  errors  have  been  reduced  by  improved  manufacturability  checking.  The  checking 
has  improved  in  the  areas  of  detecting  logical/physical  conversion  problems  by  netlist  comparison 
capabilities,  minimum  line  segment  lengths  detection,  more  automatic  nomenclature  cell  creation 
for  the  checking  system,  and  improvements  in  the  types  of  connectivity  recognized  (both  point  to 
point  and  overlapping  connectivity). 

2.4.4.1.1  Production  Modules 

The  data  required  to  build  production  modules  is  identical  to  building  prototypes.  However, 
production  MCM  release  has  a  more  rigid  documentation  release  path  and  unique  paths  for 
transformation  of  verified  design  data  into  tool  sets  defined  for  both  Ceramic  and  Thin-Film  MCM 
technology.  The  major  differences  being  formalized  part  numbers,  mechanical  drawing  format 
requirements,  and  a  more  formal  design  review  process.  These  can  add  another  week  into  the 
process,  though  prior  to  the  current  ‘E.Fishkill  Packaging  Development  Checkpoint  Process’  this 
could  take  more  than  double  the  time. 

2.4.4.1.2  Logic  Entry 

In  the  logic  entry  path  scenario,  a  netlist  with  constraints,  along  with  chip  information  and  a 
package  description,  defines  a  product  whose  physical  design,  fabrication,  assembly,  and  test  is  to 
be  completed  at  the  foundry.  The  interfaces  defined  are  for  cases  2  and  3. 


Case 

Logic  Design 

Physical  Design 

Release 

2 

Customer(Cadence) 

IBM(Cadence) 

IBM(Intemal) 

3 

Customer(MGC) 

IBM(Cadence) 

IBM(Intemal) 

The  physical  design  process  used  is  the  one  defined  in  the  MCM  design  kit  created  for  the  Cadence 
tool  set.  The  basic  activity  blocks  of  time  for  physical  design  are  depicted  by  the  following  list  of 
activities: 

Library  Development 

•  Create  Pad  stacks 

•  Create  Symbols 

•  Create  (Template) 
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Customer  Review/Netlist  Preparation 

•  Reformat/Edit/Review  Netlist 

Physical  Design 

•  Open  Board  Template/Verify  Cross-section/Import  the  Netlist 

•  Create  Blind/Buried  Vias 

•  Place  Symbols 

•  Run  Z  Router  (‘C’  Tech) 

•  Run  Routers 

•  Interactive  Routers 

•  Power  Planes 

•  DRC  recheck 

MDS  (Manufacturability)  Verification  &  Release 

•  Conversion  to  Internal  Manufacturing  format  (NL1) 

•  Manufacturability  verification 

•  Design  Review 

•  Design  Storage/Data  Documentation 

•  Data  Transformation 


The  product  specifications  and  design  documentation,  described  or  referenced  from  the  DOE,  are 
used  to  fully  define  the  product  and  insure  that  the  solution  meets  all  user  requirements.  Similarly 
when  test  is  part  of  the  agreed  work-scope  on  a  product  being  delivered,  appropriate  test  data  has 
to  get  to  the  right  manufacturing  operations. 

Cadence  Logic  Entry  Demonstration 

With  native  information  formats,  the  transfer  of  information  occurs  smoothly  from  the  Cadence 
logic  design  environment  to  the  Cadence  Physical  design  tools  used  by  the  foundry. 

Numerous  designs  have  been  processed  from  Cadence  front  end  tools  using  the  native  exchange 
files.  All  have  been  successful. 

Sun  Microsystems,  Inc. 

Process  Overview 

The  development  of  the  MCM  began  with  a  preliminary  hard-copy  input  from  Sun  Microsystems 
Inc.,  describing  the  physical  aspects  and  power  attributes  of  the  devices  to  be  packaged.  This 
developed  into  a  ‘Document  of  Understanding’  which  was  the  precursor  to  the  currently  required 
‘Document  of  Execution’.  The  product  requirements,  proposed  solution,  and  program 
responsibilities  are  describe  in  that  document. 

Upon  receipt  of  the  netlist  from  Sun  Microsystems,  Inc.  the  development  of  the  MCM  proceeded 
along  five  concurrent  paths:  electrical  and  physical  design  of  the  substrate;  thermal  analysis  and 
design  of  encapsulation  hardware;  Flip  Chip  wafer  bumping;  module  interconnect  test;  and  module 
functional  test.  Each  of  the  five  paths  proceeded  in  a  concurrent  engineering  environment 
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encompassing  both  multiple  disciplines  and  multiple  companies  (as  in  the  case  of  discussions 
involving  the  inclusion  of  test  pins  in  the  substrate  design  to  facilitate  module  debug). 

Upon  completion  of  the  design,  a  design  review  meeting  was  held  so  that  all  manufacturing  units 
responsible  for  the  build  of  the  module  could  review  and  concur  with  the  design.  Included  in  the 
design  review  process  were  representatives  from  the  substrate  build,  bond,  assemble,  and  test 
areas.  A  design  review  was  also  held  between  the  companies  at  critical  stages  of  the  project,  to 
insure  the  module  and  the  functional  test  preparation  converge. 

Substrate  Design  &  Release 
Library  Development 

By  the  time  the  netlist  for  the  module  was  complete  the  major  library  development  work  was  done. 
One  component  footprint  (the  SRAM)  needed  modification  and  this  took  only  took  a  couple  of 
hours.  Most  of  the  time  for  this  step  is  spent  in  validation  of  hard-copy  information. 

Customer  Review/Netlist  Preparation 

A  number  of  iterations  between  the  customer  and  foundry  occurred.  This  was  for  the  most  part 
due  to  the  development  of  proposals  to  improve  performance  and  testability.  The  Cadence  third 
party  ASCII  netlist  file  format  was  the  easiest  way  to  communicate  these  updates,  so  this  format 
was  edited  and  verified  in  communication  between  the  foundry  and  Sun  Microsystems,  Inc.  The 
final  iteration  only  took  about  20  minutes,  though  iterations  occurred  over  a  few  calendar  months. 

Physical  Design 

This  whole  physical  design  process  took  about  9  hours  in  Allegro  over  the  course  of  4  days. 

Details  are  in  Table  2.4-1.  Key  to  short  cycle  time  was  the  effectiveness  of  the  Auto-Router.  A 
last  minute  change  to  power  requirements  was  requested  to  accommodate  a  separate  voltage  for  the 
Viking  chip.  Since  the  rest  of  the  design  was  unchanged,  it  was  decided  to  make  the  change  in  the 
IBM  IGS-2  design  tool  that  works  with  the  NL1  format  data  needed  for  manufacturing.  This 
choice  eliminated  the  re-conversion  and  re-verification  of  all  the  layers  that  remained  unchanged. 
The  change  took  about  8  hours  to  implement. 

MDS  (Manufacturability)  Verification  &  Release 
Standard  manufacturability  checking  was  done  and  ran  fairly  uneventfully.  Checks  required  the 
creation  of  Nomenclature  information,  that  is  semi-automatically  created  from  Cadence  ASCII 
reports.  The  checks  themselves  included  cursory  processability  checks  (level  checks),  layer  checks 
(spacing,  widths,  grid  characterization,  minimum  line  segment  lengths,  and  metal  density),  Z  rule 
checks.  Continuity  checks,  and  final  processability  (report)  runs.  A  comparison  of  the  physically 
generated  netlist  is  made  against  the  original  logic  (Allegro)  netlist,  to  insure  proper  conversion. 
This  took  about  30  hours. 

Design  documentation  was  completed  outside  the  critical  product  cycle  path.  The  top  and  bottom 
surface  design  drawings  were  imported  to  a  CADAM  tool  where  the  substrate  tolerances  were 
placed  on  the  drawings.  A  substrate  layer  drawing  was  also  generated,  describing  the  function  of 
each  of  the  individual  substrate  layers.  The  drawings  were  placed  on  the  IBM  part  number  list, 
controlled  by  a  Product  Engineer,  with  all  changes  requiring  concurrence  by  the  engineering  team 
responsible  for  the  project  (Team  consists  of  Manufacturing,  Product,  Development,  and 
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Applications  Engineers).  The  substrate  was  not  built  on  the  Manufacturing  line,  but  on  the 
prototype  line,  using  an  Electron  Beam  tool  (E-BEAM),  which  produces  substrate  layers  without 
using  metal  masks.  Details  on  the  E-BEAM  tool  processing  are  in  the  section  on  ‘Manufacturing 
Tools  Release  Paths  and  Validation’. 

The  test  data  requirements  were  also  satisfied  outside  the  critical  path.  Substrate  opens  and  shorts 
test  data  was  generated  from  the  verified  design  data.  Module  (Interconnect)  test  chip  BSDL, 
SRAM  functional  descriptions,  and  netlist  information  was  provided  to  module  product  engineers 
to  satisfy  test  engineering  information  requirements. 

Flip  Chip  Bumping 

For  this  module,  not  only  was  the  MCM  physical  design,  assembly,  and  build  performed,  but  the 
die  were  converted  from  their  original  wire  bond  format  into  a  flip  chip  (C4)  format.  This  design 
was  also  done  in  the  Cadence  Allegro  system  and  released  to  the  wafer  bumping  organization. 
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Table  2.4-1  Cycle  time  breakdown  of  the  Design  and  CAD  Data  Verification  activities  for  the 
Sun  Microsystem  Design 


Library  Development _ _ 

Create  Pad  stacks _ 

Create  Symbols  " 

Create  (Template)  _ 

Customer  Review/Preparation _ 

Reformat/Edit/Review  Netlist  " 

Physical  Design  ~~  ~~ 


Open  Board  Template  /Verify  Cross-section 
_ Create  Blind/Buried  Vias 


Place  Symbols 


Run  Z  Router  (‘C’  Tech)  _ 

Run  Routers 


Interactive  Routers 


Power  Planes 


DRC  recheck 


Total  Allegro  Design  Days 


Hours 

0 


Comments _ 

1  Symbols  (1  chip)  the  rest 
existed 


Third  Party  Format  (includes 
inputting  to  Allegro) 


0 


0.1 


0.1 


0 


3 


3 


0.25 


0 


(8.75 

hours) 


(previous  strateg 


5  Overflow  nets 


6  Planes 


4  Days 


defined) 


Cadence  Physical  Design  Release 


GL1  Converter 


IGS-2  Additional  Power  Plane  Desi 


_ Nomenclature  Cell  Creation 


Read  Nomenclature 


Processability/Level  checks 


Layer  Checks 


PD  checks 


ORBOT  checks. 


Metal  area  checks. 


Z  rules  checks 


Continui 


Logical/physical  Comparison 


Design  Review 


Total  CAD  Data  Verification  Days 


Total  'SUN'  Design  &  CAD  Data  Verification  (39  hours) 
Days 


11  out 


(New  Split  Mesh  for  Viking) 


4  Days 


9  Days 
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National  Semiconductor 
Process  Overview 

The  development  of  the  MCM  began  with  preliminary  hard-copy  input  from  National 
Semiconductor  describing  the  physical  aspects  and  power  attributes  of  the  devices  to  be  packaged. 
This  developed  into  the  currently  required  ‘Document  of  Execution’.  The  product  requirements, 
proposed  solution,  and  program  responsibilities  are  described  in  that  document. 

A  partial  netlist  was  received  from  National  Semiconductor  and  remaining  necessary  physical 
design  activity  was  started. 

Upon  completion  of  the  design,  a  design  review  meeting  was  held  so  that  all  manufacturing  units 
responsible  for  the  build  of  the  module  could  review  and  concur  with  the  design.  Included  in  the 
design  review  process  are  representatives  from  the  substrate  build,  bond,  assemble,  and  test  areas. 
A  design  review  was  also  held  between  the  companies  at  critical  stages  of  the  project,  to  insure  the 
module  and  die  functional  test  preparation  converge. 

Substrate  Design  &  Release 
Library  Development 

New  padstacks,  chip  footprints,  device  files,  and  a  module  template  was  needed  for  this  design. 
Nothing  unusual  was  encountered  and  the  activity  took  about  7  hours  to  complete. 

Customer  Review/Netlist  Preparation 

Since  only  a  partial  netlist  was  provided,  the  rest  was  added  with  an  editor.  The  Cadence  third 
party  ASCII  nedist  file  format  was  used  to  communicate  and  verify  the  updates  with  National 
Semiconductor.  About  6  hours  was  spent  making  the  necessary  modifications. 

Physical  Design 

The  physical  design  had  unique  requirements  that  lead  to  100%  manual  routing.  This  took  roughly 
4  days  in  the  Cadence  Allegro  System  and  contributed  to  half  the  design  time.  Problems  also 
occurred  trying  to  use  the  plane  generation  SKILL  routines,  so  they  were  only  partially  completed 
in  Allegro,  though  2  days  were  spent  trying.  Total  design  time  in  Allegro  was  about  8  days. 

Power  planes  were  completed  in  IBM’s  IGS-2  environment,  with  another  day’s  effort. 

MDS  (Manufacturability)  Verification  &  Release 

Standard  manufacturability  checking  was  done  and  ran  fairly  uneventful.  Nomenclature  checking 
information  was  semi-automatically  created  from  Cadence  ASCII  reports.  The  checks  themselves 
included  cursory  processability  checks  (level  checks),  layer  checks  (spacing,  widths,  grid 
characterization,  and  metal  density),  Z  rule  checks.  Continuity  checks,  and  final  processability 
report  runs.  A  comparison  of  the  physically  generated  netlist  was  made  against  tire  original  logic 
(Allegro)  netlist,  to  insure  proper  conversion.  This  took  about  3  days. 

There  was  another  days  effort  creating  design  review  documentation,  a  contingency  day,  then  the 
design  review.  Total  calendar  cycle  was  15  days  from  input  through  reviewed  design.  A  rough 
distribution  between  tasks  is  listed  in  Table  2.4-2. 

Design  documentation  was  completed  outside  the  critical  product  cycle  path  .  The  top  and  bottom 
surface  design  drawings  were  imported  to  a  CAD  AM  tool  where  the  substrate  tolerances  were 
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placed  on  the  drawings.  A  substrate  layer  drawing  was  also  generated,  describing  the  function  of 
each  of  the  individual  substrate  layers.  The  drawings  were  placed  on  the  IBM  part  number  list, 
controlled  by  a  Product  Engineer,  with  all  changes  requiring  concurrence  by  the  engineering  team 
responsible  for  the  project  (Team  consists  of  Manufacturing,  Product,  Development,  and 
Applications  Engineers).  The  substrate  was  built  on  the  Manufacturing  line,  which  produces 
substrate  layers  using  metal  masks.  Details  on  the  Ceramic  Standard  Tooling  processing  are  in  the 
section  on  'Manufacturing  Tools  Release  Paths  and  Validation’. 

Also  outside  the  critical  path,  substrate  opens  and  shorts  test  data  was  generated. 
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Table  2.4-2  Approximate  cycle  time  breakdown  of  the  Design  and  CAD  Data  Verification 
activities  for  the  National  Semiconductor  Desi 


Library  Development 


Create  Pad  stacks 


Create  Symbols 


Create  (Template' 


Customer  Review/Preparation 


Reformat/Edit/Review  Netlist 


Hours 


1 


Comments 


2  Symbols  (1  chip,  1  BSM 


Partial  netlist  &  Reformat 
activity  (includes  inputting  to 
Allegro) 


Create  Blind/Buried  Vias 


Place  Symbols 


Run  Z  Router  (‘C’  Tech) 


Run  Routers 


Interactive  Routers 


Power  Planes 


DRC  recheck 


Total  Allegro  Design  Davs 


Cadence  Physical  Design  Release 


GL1  Converter 


IGS-2  Additional  Power  Plane  Desi 


Nomenclature  Cell  Creation 


Read  Nomenclature 


Processability/Level  checks 


Layer  Checks 


PD  checks 


ORBOT  checks. 


Metal  area  checks. 


Z  rules  checks 


Continui 


Logical/physical  Comparison 


Processability/Release  (Summaries/plots) 


Design  Review  (wait) 


Design  Review 


Total  CAD  Data  Verification  Davs 


Total  ’National*  Design  &  CAD  Data 
Verification  Davs 


Partial  Success  /  remainder  in 
IGS/NL1 


11  out,  level  modifications 


2.5 


1.5 


1.5 


2 


6 


3 


8 


8 


8 


(58  hours) 


7  Days 


15  Days 


TDV  Subset  Design 

This  design  was  processed  to  allow  comparisons  of  the  different  paths  associated  with  design  data 
verification  and  release.  Table  2.4-3  indicates  cycle  time.  No  documentation  release  was 
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processed  or  tooling  data  created. 


Table  2.4-3  Cycle  time  breakdown  of  the  Design  and  CAD  Data  Verification  activities 
for  the  TDV  Subset  Design 

Library  Development 

Hours 

Comments 

Create  Pad  stacks 

0 

Create  Symbols 

0 

Create  (Template) 

0 

Customer  Review/Preparation 

Reformat/Edit/Review  Netlist 

0 

Physical  Design 

Open  Board  Template/Verify  Cross-section 

0.16 

Create  Blind/Buried  Vias 

0 

Place  Symbols 

0.16 

Run  Z  Router  (‘C’  Tech) 

- 

Rim  Routers 

0.92 

Redist.  Pgm,  Autoroute, 
Gloss 

Interactive  Routers 

0 

Power  Planes 

1.25 

Mesh  Pgm  2  planes 

DRC  recheck 

0.33 

line  segments,  &  reports 

Total  Allegro  Days 

(2.82 

hours) 

Cadence  Physical  Design  Release 

GLl  Converter 

1 

gllout,  level 
modifications 

Nomenclature  Cell  Creation 

1 

Initial  Creation 

Read  Nomenclature 

3 

! 

Editing  for  wirebond  pad 
location  round-off 
corrections  included 

Processability/Level  checks 

0.16 

Layer  Checks 

P  D  checks 

1.35 

ORBOT  checks. 

0.16 

Metal  area  checks 

0.5 

Min  Line  Segment  checks 

0.16 

Z  rules  checks 

1 

Continuity 

5 

Logical/physical  Comparison 

0.16 

Processability/Release  (Summaries/plots) 

8 

Estimated  (test  case  only) 

Design  Review  (wait) 

0 

Design  Review 

2 

Estimated  (test  case  only) 

Total  CAD  Data  Verification  Days 

(23.49 

hours) 

3  Days 

Total  ‘TDV  Subset’  Design  &  CAD  Data 
Verification  Days 

(26.31 

hours) 

3.29  Days 
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Mentor  Graphics  Logic  Entry  Demonstration:  TDV  -  Subset  Design 

A  customer  using  Mentor  Graphics  Corporation  logic  design  tools  would  use  the  native  files  or  an 
EDIF  'Schematic'  path. 

The  native  Mentor  Graphics  physical  interface  files,  the  'NETS',  'COMPS',  and  'GATES'  files  can 
be  converted  to  the  Cadence  Allegro  'Third  Party'  format.  The  path  used  was  to  convert  the 
■NETS',  'COMPS',  and  'GATES'  files  to  the  'neutral_file'  format  and  use  the  physical  design  entry 
program  'MgcToCad'  to  create  the  Allegro  format.  A  separate  program  could  be  written  to  do  the 
conversion  if  justified  by  business  needs. 

When  exercising  the  EDIF  data  exchange  path,  the  non-standard  properties  used  to  convey 
standard  information  became  very  obvious.  Cadence  EDIF-Read,  EDIF-Write  were  configured  to 
exchange  schematic  information  with  Mentor  Graphics’  Design  Architect.  However,  significant 
additional  library  information  had  to  be  developed  to  ‘Package’  the  schematic  for  physical  design 
after  the  EDIF  conversion  occurred.  If  a  number  of  design  conventions  were  followed  when  in  the 
Mentor  Graphics  Design  Architect  tool,  the  EDIF  transfer  could  be  more  effective,  however  the 
need  for  these  convention  requirements  only  further  decreased  the  desirability  of  this  path. 

The  other  limitation  that  becomes  apparent  in  the  EDIF  exchange  path  is  that  full  'EDIF  Schematic' 
replacement  is  possible  but  'EDIF  Update'  is  not.  This  may  be  unacceptable  to  Logic  design  due  to 
the  fact  that  a  replaced  logic  design  may  require  complete  re-verification  of  the  intended 
functionality. 

The  EDIF  path  is  possible,  but  not  recommended  due  to  items  identified  above. 

Expected  cycle  time  is  the  same  as  the  Cadence  Logic  entry  path  with  the  additional  cycle  time 
associated  with  the  conversion  (less  than  an  hour).  Though  the  Mentor  Graphics  path  has  been 
exercised  there  is  no  "non-test-case"  experience  at  this  time. 

2.4.4.1.3  Physical  Entry 

In  the  Physical  Entry  path  scenario,  a  completed  physical  design  along  with  a  package  description 
and  specifications  defines  a  product  whose  fabrication,  assembly,  and  test  is  to  be  completed  at  the 
foundry.  The  interfaces  defined  are  for  cases  4,  5,  and  6. 


Case 

Logic  Design 

Physical  Design 

Release 

4 

IBM(Intemal) 

5 

Customer(MGC) 

Custamer(MGC-Gerber) 

IBM(Intemal) 

6 

Customer(MGC) 

Customer(MGC-GDS2) 

IBM(Intemal) 

The  foundry  physical  entry  strategy  supports  data  entry  from  Cadence  and  Mentor  Graphics  design 
systems.  The  Cadence  input  data  is  the  Cadence  board  file,  while  the  Mentor  Graphics  input  is 
made  up  of  text  based  files  and  Gerber  or  GDS2  artwork  files. 

In  general  the  process  steps  are  as  follows: 

MDS  (Manufacturability)  Verification  &  Release 

•  Conversion  to  Internal  Manufacturing  format  (NL1) 

•  Manufacturability  verification 
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•  Design  Review 

•  Design  Storage/Data  Documentation 

•  Data  Transformation 

The  product  specifications  and  design  documentation,  described  or  referenced  from  the  DOE,  are 
used  to  fully  define  the  product  and  insure  that  the  solution  meets  all  user  requirements.  Similarly 
when  test  is  part  of  the  agreed  work-scope  on  the  product  being  delivered,  appropriate  test  data  has 
to  get  to  the  right  manufacturing  operations. 

Text  and  CAD  data  converters  are  used  in  processing  the  input  data  files,  and  generate  GL1  data 
and  other  associated  files  necessary  for  foundry  design  checking  and  release.  For  Cadence  input, 
the  gllout  and  pin.extract  converters  are  used.  The  common  Mentor  Graphics  converters  are  the 
MgcToCad  program,  the  pin.extract  program,  and  IGS-2.  For  Mentor  Graphics  GDS2  input,  the 
GDS2  to  GL1  conversion  program  is  utilized  while  the  Cadence  Gerber  read  and  gllout  programs 
are  used  in  the  Gerber  input  case. 

The  outputs  of  these  conversion  programs,  netlist,  nomenclature,  and  NL1  data,  are  the  inputs  to 
the  Manufacturability  checking  (MDS)  and  release  system.  The  MDS  system  performs 
processability,  layer  rule,  Z  rule,  and  continuity  checks  on  the  NL1  data.  The  final  step  in  this 
process  is  a  logic/physical  comparison,  ensuring  that  the  NL1  data  from  the  conversion  process 
physically  adheres  to  the  functions  defined  in  the  logic  netlist. 

The  design  is  then  be  reviewed  at  a  design  review,  and  upon  concurrence  with  manufacturing 
representatives,  released  to  the  ISM  data  base.  The  verified  CAD  data  is  used  in  the  data 
transformation,  or  post  processing  steps. 

Cadence  Physical  Entry  Demonstration 

Early  in  the  IBM/Cadence  company  relationship,  a  converter  was  written  for  the  conversion  of  the 
Cadence  internal  database  format  to  the  IBM  internal  format  (GL1).  Since  this  path  exists,  the 
standard  process  for  releasing  physical  designs  to  the  foundry  is  by  shipping  the  Cadence  board 
(.brd)  file.  The  board  file  provides  both  the  physical  and  logic  information  required.  Many  MCM 
designs  have  been  released  to  the  foundry  from  both  internal  IBM  designers  and  OEM  customers 
who  use  Cadence  tools. 

General  Process 

The  general  steps  within  the  Cadence  Physical  Entry  process  are  as  follows: 

•  Conversion  to  Internal  Manufacturing  format  (NL1) 

•  GL1  Converter 

•  Manufacturability  verification 

•  Nomenclature  Cell  Creation 

•  Read  Nomenclature 

•  Processability/Level  checks 

•  Layer  Checks 

=>  PD  checks 
=>  ORBOT  checks 
=>  Metal  area  checks 
=>  Minimum  Line  Segment  Checks 

•  Z  rules  checks 
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•  Continuity 

•  Logical/physical  Comparison 

•  Processability/Release 

McClellan  AFBALC 
Process  Overview 

The  development  of  the  MCM  began  with  a  hard-copy  proposal  from  McClellan  AFB  ALC  for  a 
solution  to  their  Data  Transfer  Module  (DTM)  needs.  The  proposal  outlined  the  physical  and 
electrical  attributes  of  the  devices  to  be  packaged  on  the  substrate.  This  information,  along  with 
the  system  information  including  environmental,  physical,  and  power  attributes,  allowed  the 
application  team  to  generate  a  preliminary  proposal.  Working  with  McClellan  AFB-ALC,  the 
application  team  was  able  to  refine  the  proposal  to  provide  McClellan  AFB-ALC  with  a  cost 
effective,  efficiently  manufacturable  MCM  which  met  their  overall  application  requirements  for  the 
DTM.  Final  requirements  and  agreements  are  documented  in  the  DOE  per  the  ‘Packaging 
Development  Checkpoint  Process’. 

A  completed  physical  design  was  released  to  the  Foundry.  The  design  data  was  converted  into  the 
internal  format,  verified  against  manufacturability  requirements,  and  released.  While  the  logic  and 
physical  design  was  being  performed  at  McClellan  AFB-ALC,  the  interconnect  test  development 
was  concurrently  being  done  within  the  IBM  Poughkeepsie  facility.  This  concurrent  engineering 
activity  allowed  for  a  reduced  product  cycle  time  as  test  was  debugged  and  ready  when  the 
substrates  completed  the  die  bonding  process.  The  DTM  module  was  delivered  8  weeks  after  the 
design  data  was  received. 

Conversion  to  Internal  Manufacturing  format  (NL1) 

The  conversion  went  smoothly  due  to  the  feet  that  design  kit  defined  conventions  were  followed. 

The  entire  cycle  took  about  1  hour  and  20  minutes. 

Manufacturability  verification 

This  too  went  smoothly  and  the  design  data  was  verified  within  a  few  days.  Details  are  in  Table 
2.4-4. 

Documentation  and  test  data  release  was  processed  outside  of  the  critical  path. 
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Table  2.4-4  Cycle  time  breakdown  of  the  CAD  Data  Verification  activities  for  the 
McClellan  AFB  ALC  DTM  Design 

Cadence  Physical  Design  Data  Verification 

Hours 

Comments 

GL1  Converter 

1.33 

gllout,  level 
modifications 

Nomenclature  Cell  Creation 

3 

Read  Nomenclature 

0.33 

Processability/Level  checks 

0.16 

Layer  Checks 

PD  checks 

2.33 

ORBOT  checks 

0.16 

Metal  area  checks 

0.5 

Minimum  Line  Segment  check 

0.16 

Z  rules  checks 

0.5 

Continuity 

5 

Logical/physical  Comparison 

0.16 

Processability/Release  (Summaries/plots) 

8 

Design  Review  (wait) 

0 

Design  Review 

2 

Total  CAD  Data  Verification  Days 

E9SH 

3  Days 

Additional  Demonstrations: 

Mayo  ‘C’  and  ‘D’  Test  vehicle  designs  were  also  received  as  completed  physical  designs  and 
released  to  the  respective  tool  sets.  Both  these  were  test  vehicle  modules  that  followed  no 
conventions  but  were  successfully  built  and  delivered  to  the  customer.  CAD  data  verification  took 
about  8  days  of  special  processing  for  the  (first)  'C'  test  vehicle,  then  about  5  days  for  the  'D'  test 
vehicle  due  to  development  of  checking  procedures  from  the  first  experience. 

TDV  Subset  Design 

The  general  process  for  the  Cadence  release  path  has  been  outlined  above  in  the  Cadence  physical 
entry  section.  Table  2.4-5  describes  cycle  times  and  any  discoveries  and  deviations  noted  during 
the  actual  TDV  subset  release  test  case. 
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Table  2.4-5  Cycle  time  breakdown  of  the  CAD  Data  Verification  activities  for  the 

TDV  Subset  Design 

Cadence  Physical  Design  .brd  file 

Hours 

Comments 

GL1  Converter 

1 

gllout,  level 
modifications 

Nomenclature  Cell  Creation 

1 

Read  Nomenclature 

3 

Processability/Level  checks 

0.16 

Layer  Checks 

PD  checks 

1.35 

ORBOT  checks. 

0.16 

Metal  area  checks. 

0.5 

Min.  Line  Segment  Checks 

0.16 

Z  rules  checks 

1 

Continuity 

\5~ 

Logical/physical  Comparison _ 

0.16 

Processability/Release  (Summaries/plots) 

8 

Estimated  (test  case  only) 

Design  Review  (wait) 

0 

Design  Review 

2 

Estimated  (test  case  only) 

Total  CAD  Data  Verification  Days 

(23.49 

hours) 

3  Days 

Mentor  Graphics  Physical  Entry  Demonstration 

The  foundry  physical  entry  supports  entry  from  the  Mentor  Graphics  design  system  using  either 
GDS2  or  GERBER  as  the  graphic  data  transfer  medium.  In  both  cases,  text  files  will  be  used  to 
determine  logic  and  placement  requirements,  while  the  routing  information  will  be  conveyed  by 
GDS2  or  Gerber  binary. 

General  Process 

The  general  steps  within  the  Mentor  Graphics  Physical  Entry  process  are  as  follows: 

•  Conversion  to  Internal  Manufacturing  format  (NL1) 

•  ASCII  Conversion  of  Netlist,  Footprints,  Placement  data 

•  Artwork  Conversion  and  Editing 

•  Manufacturability  verification 

•  Nomenclature  Cell  Creation 

•  Read  Nomenclature 

•  Processability/Level  checks 

•  Layer  Checks 

=>  PD  checks 
=>  ORBOT  checks 
=>  Metal  area  checks 
=>  Minimum  Line  Segment  Checks 

•  Z  rules  checks 

•  Continuity 
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Logical/physical  Comparison 
Processability/Release 


Gerber  -  TDV  Subset  Design 

The  data  exchange  from  Mentor  Graphics  utilizes  Gerber,  augmented  by  logic  and  device 
information  in  an  ASCII  format.  The  ASCII  format  chosen  is  the  standard  Mentor  Graphics 
'neutral  file'  from  the  FABLINK  tool.  The  'neutral  file’  is  further  augmented  by  the  Tech  file,  that 
describes  the  template  from  which  the  design  was  created.  This  has  more  information  than 
minimally  required  but  is  easy  to  generate  by  the  customers. 

A  program  named  'MgcToCad'  uses  the  'neutral  file'  data  and  'tech  file*  to  recreate  the  device 
information,  placement  information,  and  netlist  information,  which  is  then  used  to  create  a  Cadence 
•brd  file  with  placed  components.  The  MDS  Nomenclature  cell  is  generated  from  the  placed  board 
information.  The  Nomenclature  cell  is  used  to  guide  the  internal  checking  tools  (MDS)  to  verify 
the  converted  Gerber  or  GDS2  data.  The  converted  and  verified  CAD  data  is  used  to  create  the 
substrate  opens  and  shorts  test  data.  The  verified  design  data  also  supports  manufacturing 
assembly  and  documentation  requirements. 

Release  of  the  completed  physical  design  data  from  the  Mentor  Graphics  tools  has  been 
demonstrated.  Ongoing  refinement  is  expected  as  technology  and  tool  developments  occur.  Details 
are  described  in  Table  2,4-6. 
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Table  2.4-6  Cycle  time  breakdown  of  the  CAD  Data  Verification  activities  for  the 

TDV  Subset  Design 

Mentor  Graphics  Gerber  Data 

Hours 

Comments 

MgcToCad  Conversion 

4 

Debug  required  due  to 
differences  in  expected 
pad  types,  1  hour  for 
clean  run. 

Gerber  Conversion  to  GL1 

1.5 

GL1  Editing/Conversion  to  NL1 

3.75 

Top  surface  pads  were 
drawn  not  flashed  so 
surface  features  from  the 
placed  board  was 
required. 

Nomenclature  Cell  Creation 

5 

Single  point  nets  were  not 
in  the  netlist,  so  view 
names  for  those  pads  in 

NL1  had  to  be  changed. 

Read  Nomenclature 

5 

A  round  off  error 
required  modification  to 
roughly  300  pad 
locations. 

Processability/Level  checks 

0.16 

Layer  Checks 

PD  checks 

0.67 

ORBOT  checks. 

0.16 

Metal  area  checks. 

1.5 

Min.  Line  Segment  Checks 

0.16 

Continuity 

0.5 

Logical/physical  Comparison 

0.16 

Processability/Release  (Summaries/plots) 

8 

Estimated  (Test  Case 
only) 

Design  Review  (wait) 

0 

Design  Review 

2 

Estimated  (Test  Case 
only) 

Total  CAD  Data  Verification  Days 

\U4-A  ‘A  _ J? _  ,  ■  1 

(32.56 

hours) 

4  Days 

-  X  - - - — - —  -V  wvwv^i.  M*v  kVfcM.  WUUV  WliVUUVUO.  1  1X10 

would  result  in  a  3  hour  savings.  Similarly,  fixing  the  round  off  problems  with  the  pad  locations 
will  save  4  hours,  and  developing  an  alternate  approach  to  single  point  nets  will  save  an  additional 
3  hours  bringing  the  CAD  Data  Verification  time  down  to  22.56  hours  or  just  under  3  days. 


GDS2  -  TDV  Subset  Design 

The  GL1  editing  is  required  to  separate  GDS2  layers  into  GL1  layers  and  change  shape  names  to 
those  that  are  processable.  (The  Gerber  method  is  automatically  correctly  separated  and  named.) 
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The  GDS2  data  can  be  processed  by  the  foundry,  but  is  currently  inherently  more  complicated 
because  of  the  less  specific  conversion  to  GL1  and  because  redistribution/mesh  layers  in  the  GDS2 
violate  ground  rules  and  create  self  intersecting  shapes  that  have  to  be  edited  out  of  the  data. 


Details  are  described  in  Table  2.4-7. 


Table  2.4-7  Cycle  time  breakdown  of  the  CAD  Data  Verification  activities  for  the 

TDV  Subset  Design 

Mentor  Graphics  GDS2  Data 

Hours 

Comments 

MgcToCad  Conversion 

4 

Same  as  Gerber 

GDS2GL1 

0.25 

GDS2  required  pin.extraction 

0.58 

GL1  Editing/Conversion  to  NL1 

1.75 

Nomenclature  Cell  Creation 

5 

Same  as  Gerber 

Read  Nomenclature 

5 

Same  as  Gerber 

Processability/Level  checks 

0.16 

Layer  Checks 

PD  checks 

1.33  + (8 
see  note 
below) 

ORBOT  checks. 

0.16 

Metal  area  checks. 

0.5 

Min.  Line  Segment  Checks 

0.16 

Continuity 

3 

Debug,  self  intersecting 
shapes  detected  at  this 
step.  Edits  and 
interactions  required. 

Logical/physical  Comparison 

0.16 

Processability/Release  (Summaries/plots) 

8 

Estimated  (Test  Case 
only) 

Design  Review  (wait) 

r° 

Design  Review 

2 

Estimated  (Test  Case 
only) 

Total  CAD  Data  Verification  Days 

(40.05 

hours) 

5  Days 

Since  editing  this  data  would  have  taken  an  additional  estimated  8  hours,  the  equivalent  Gerber 
layer  data  was  used  for  the  redistribution/mesh  layer.  Using  the  equivalent  Gerber  layer  allowed 
verification  that  the  rest  of  the  GDS2  data  processed  normally. 


2.4.4.2  Manufacturing  Tools  Release  Paths  and  Validation 

This  section  will  address  the  data  transformation  aspects  of  the  release  system  to  support  the 
specific  manufacturing  tool  sets  for  the  Ceramic  and  Thin-Film  MCM  manufacturing  capabilities. 
Table  2.4-8  describes  the  different  ways  the  design  features  are  implemented  in  each  of  the 
technologies. 
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1 

Manufacturing  Process  1 

■  ■ 

MCM-D 

MCM-C  1 

Standard/Prototype 

Standard 

Prototype 

Pattern 

Metal  Mask 

E-BEAM  Data 

Vias 

Laser  Mask 

Punch  Data 

E-BEAM  Data 

Table  2.4-8:  Techno! 


logy  feature  definition  approach  (repeat  of  Figure  2.4-3) 


2.4.4.2.1  Prototype 

Prototype  MCM  release  has  a  common  strategy  for  documentation  release,  and  unique  paths  for 
transformation  of  verified  design  data  into  tool  data.  The  three  transformation  options  are: 


•  Ceramic  Technology  Prototype  Tooling 

•  Ceramic  Technology  Standard  Tooling 

•  Thin  Film  Technology  Prototype  (same  as  Standard)  Tooling 


Ceramic  Technology  Prototype  Tooling 

As  described  in  the  “ASEM  Report  on  the  Process  and  Methodology  within  the  Release  System”, 
verified  design  data  and  marked  up  plots  are  provided  to  the  E-BEAM  tool  engineers  who  process 
the  data.  The  E-BEAM  tool  does  a  direct  write  of  the  pattern  and  vias  needed  for  the  product. 

The  Sun  Sparc  module  was  built  with  this  tooling.  The  design  data  was  provided  to  the  Engineer 
responsible  for  the  Electron  Beam  (E-BEAM)  tool.  The  engineer  converted  the  data  to  a  tool 
format,  and  proceeded  with  the  build  of  the  module.  Total  processing  for  the  tools  was  less  than  4 
hours. 


Ceramic  Technology  Standard  Tooling 

Data  is  generated  to  create  the  artwork  for  the  masks,  the  artwork  for  via  inspection  masks,  the 
data  for  the  punch  (vias)  tools,  and  automatic  inspection  tools  as  needed.  Due  to  the  increase  in  the 
number  of  tools,  the  additional  work  associated  with  releasing  the  CC’  standard  tooling  data  is 
much  greater  than  that  of  the  ‘C’  prototype  tooling  path.  Cycle  time  is  also  affected  by  the 
requirement  of  metal  mask  fabrication  for  this  process. 

The  critical  path  is  Design  Data  on  ISM,  post  processing,  Mask  EWR  generation,  and  Metal  mask 
delivery.  This  process  has  been  improved  by  the  integration  of  the  transformation  tools  within  the 
'BRX'  system  framework. 
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. . 

Manufacturing  Process  1 

■ 

MCM-D 

MCM-C 

Standard/Prototype 

Standard 

Pattern 

Metal  Mask 

E-BEAM  Data 

Vias 

Laser  Mask 

Punch  Data 

E-BEAM  Data 

Table  2*4-8:  Technology  feature  definition  approach  (repeat  of  Figure  2.4-3) 


2.4.4.2.1  Prototype 

Prototype  MCM  release  has  a  common  strategy  for  documentation  release,  and  unique  paths  for 
transformation  of  verified  design  data  into  tool  data.  The  three  transformation  options  are: 

•  Ceramic  Technology  Prototype  Tooling 

•  Ceramic  Technology  Standard  Tooling 

•  Thin  Film  Technology  Prototype  (same  as  Standard)  Tooling 

Ceramic  Technology  Prototype  Tooling 

As  described  in  the  “ASEM  Report  on  the  Process  and  Methodology  within  the  Release  System”, 
verified  design  data  and  marked  up  plots  are  provided  to  the  E-BEAJM  tool  engineers  who  process 
the  data.  The  E-BEAM  tool  does  a  direct  write  of  the  pattern  and  vias  needed  for  the  product. 

The  Sun  Sparc  module  was  built  with  this  tooling.  The  design  data  was  provided  to  the  Engineer 
responsible  for  the  Electron  Beam  (E-BEAM)  tool.  The  engineer  converted  the  data  to  a  tool 
format,  and  proceeded  with  the  build  of  the  module.  Total  processing  for  the  tools  was  less  than  4 
hours. 

Ceramic  Technology  Standard  Tooling 

Data  is  generated  to  create  the  artwork  for  the  masks,  the  artwork  for  via  inspection  masks,  the 
data  for  the  punch  (vias)  tools,  and  automatic  inspection  tools  as  needed.  Due  to  the  increase  in  the 
number  of  tools,  the  additional  work  associated  with  releasing  the  ‘C’  standard  tooling  data  is 
much  greater  than  that  of  the  CC5  prototype  tooling  path.  Cycle  time  is  also  affected  by  the 
requirement  of  metal  mask  fabrication  for  this  process. 

The  critical  path  is  Design  Data  on  ISM,  post  processing.  Mask  EWR  generation,  and  Metal  mask 
delivery.  This  process  has  been  improved  by  the  integration  of  the  transformation  tools  within  the 
'BRX'  system  framework. 
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Process  Step 

Cycle 

Time 

Comments 

Design  Data  Documentation 

Plots,  markups,  summary  sheets  (part  of 

CAD  Data  Verification  activity) 

Mask  Control  Cards  /  Post 
Processing 

4  hours 

Control  cards  generated  from  GLP  sheets  / 
through  'BRX'  system 

Mask  EWR 

|  1  hour 

'BRX'  assisted 

Masks  Delivered 

rTypical  cycle 

Punch  Control  Cards 

1  hour 

'BRX'  assisted.  Not  Critical  Path 

Post  Process  /  Punch  Data 

3  hours 

'BRX'  assisted.  Not  Critical  Path 

Inspection  Control  Cards 

1  hour 

BRX*  assisted.  Not  Critical  Path 

Post  Process  /  Inspection  Data 

1  hour 

'BRX'  assisted.  Not  Critical  Path 

•  McClellan  AFB  ALC  Data  Transfer  Module 

•  Mayo  Ceramic  Test  Vehicle 


National  Semiconductor  Processor  Module 


Xhin  Film  Technology  Prototype  (same  as  Standard)  Tooling  -  Mavn  ‘TV 

As  described  in  the  “ASEM  Report  on  the  Process  and  Methodology  within  the  Release  System”, 
verified  design  data  and  marked  up  plots  are  provided  to  the  release  engineers  who  process  the 
data.  The  marked  up  plots  are  used  to  order  thin  film  masks  and  are  used  to  process  the  design 
data.  Cycle  time  is  affected  by  the  requirement  of  masks  for  this  process.  The  critical  path  is 
design  data  verification  (discussed  above),  design  data  on  ISM,  data  partitioning  for  thin-film 
masks,  mask  data  on  ISM,  creation  of  the  Mask  order  on  the  ’Mask  Order  Processing  System' 
(MOPS),  and  mask  delivery. 

Cycle  time  is  mmimized  by  processing  the  first  pattern  and  first  via  mask  (about  a  day),  to 

minimize  order  initiation  time,  then  processing  and  ordering  the  rest  of  the  masks  while  the  first  are 
being  built. 


Current  cycle  time  has  been  as  follows: 


Process  Step 

Cycle  Time 

Comments 

Design  Data  Partitioning  for  thin  film 
masks 

8  hours 

Design  data  is  merged  with  mask 
fiducials. 

Mask  Order/Processing  System 

Verify  windages  per  shape  levels 

Pattern  Masks  Delivered 

3  days 

Expedited  delivery 

Via  Mask  EWR 

1  hour 

Post  Process  Via  Mask  Hgfa 

2  hours 

Via  Masks 

ot  rrt  T?^l _  T" _ L  TM  •  1  1 

7  days 

Optimistic  Laser  mask  cycle 

The  Mayo  Thin  Film  Test  Vehicle'  was  processed  through  this  path. 
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2.4.4.3  Demonstration  Conclusions 

The  cycle  times  shown  represent  more  than  a  50%  reduction.  The  reduction  is  due  to 
improvements  in  the  following  areas: 

•  Improved  conversion  process  from  commercial  design  systems  and  artwork  formats  to  the  IBM 
Internal  design  data  format 

•  Improved  CAD  data  verification  capabilities 

•  Automated  release  activities  in  the  ‘BRX’  framework 

•  Formalized  and  optimized  prototype  release  requirements 

•  Streamlined  procedures  in  the  ‘E.Fishkill  Packaging  Development  Checkpoint  Process’ 

It  is  believed  that  errors  have  also  been  reduced  by  more  than  50%  by  listed  improvements,  but  a 
larger  number  of  releases  are  required  to  verify  the  exact  amount. 

Continued  cycle  time  and  error  reductions  are  expected  as  part  of  ongoing  productivity 
improvement  efforts. 

Logic  Entry 

Many  products  that  enter  this  path  have  suffered  from  data  consistency  concerns  between  bare  die 
and  package  part  I/O  and  nomenclature,  between  PCB  connector  nomenclature  and  MCM  I/O 
nomenclature,  and  between  bare  die  and  associated  test  data. 

The  bare  die  I/O  and  nomenclature  issue  specifically  refers  to  the  feet  that  the  bare  die 
configuration  of  nomenclature  and  power  pad  information  is  different  from  the  packaged  versions 
of  the  part.  This  situation  can  be  improved  through  the  availability  of  bare  die  information  in  the 
'Die  Information  Exchange  (DIE)  format'. 

Similarly,  connector  nomenclature  on  a  board  is  different  from  MCM  pin  nomenclature.  Use  of 
Design  kit  logic  symbol  elements  for  I/O  pins  will  improve  this  situation. 

The  test  data  vs.  Die  version  is  another  consistency  issue  caused  by  the  current  level  of  maturity  of 
the  organizations  providing  the  bare  die. 

Physical  Entry: 

The  easiest  physical  entry  path  is  from  Cadence  because  of  the  foundry  experience  base  and 
interchange  development  effort.  Even  this  path  though  can  be  simplified  by  minimizing  the  number 
of  individually  placed  ‘pads’  on  the  MCM.  Customers  are  encouraged  to  have  all  pads  included 
within  footprints  for  MCM  I/O  or  chip  sites. 

Gerber  and  GDS2  formats,  originally  intended  as  artwork  tool  drivers,  are  used  by  the  foundry  as 
data  exchange  formats.  The  difference  is  that,  in  a  pure  artwork  tool  environment,  it  is  not  a  major 
concern  whether  a  shape  is  created  as  a  single  entity  (e.g.  a  flash,  or  a  shape)  or  whether  it  is 
drawn  and  filled  in  with  lines  or  shapes.  For  data  exchange,  it  is  important  that  each  feature  is 
represented  as  a  single  shape  or  'flash'  of  an  aperture.  Only  lines  are  drawn,  and  those  lines  are 
drawn  from  coordinate  to  coordinate  and  should  begin  at  the  location  of  a  shape  (e.g.  pad  or  via). 
The  format  in  this  case  needs  to  be  able  to  represent  the  characteristics  of  the  technology  (e.g.  only 
circles,  rectangles  and  lines,  or  only  polygon  pads  and  circular  vias  etc.)  Also,  because  Gerber  and 
GDS2  were  not  meant  to  be  data  exchange  formats,  they  need  to  be  supplemented  by  additional 
information  encoded  as  conventions  or  supported  by  auxiliary  files  or  paper-work.  The  EDIF-PCB 
format  is  currently  under  investigation  for  extensions  into  covering  the  MCM  exchange 
requirements. 
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2.4.5  Direct  Release  Conclusions 

iVe?lK*"'[e  ma  fa°“sh  *“  °f  release  reqniremnnts 

ESjfj”  *  .  *T  °"  Arcl”t«*‘K";  Direct  Release  Aichitecture  Document,  CLIN 

MethnHnln  aT1’  10n  °ftf  p'oce!s  methodology  of  the  system  in  the  “ASEM  Report  on 
S“?S085'.&  Proc“s  Ore  *•<«*  System”  CLIN  0002 AK,  and  the  demonstration 

desenbed  in  the  Report  on  Release  System  Demonstration”  CLIN  0002AL. 

Release  continues  to  be  complicated  by  design  requirements  that  are  outside  of  the  standard 

STifi  TVen,tIOn!.  ? r°VementS  ***  flexibillty  ofthe  CAD  data  verification  tools  have 

sigmficantly  reduced 1  cycle  time  and  errors  in  the  verification  process.  Improved  conversion 
programs  and  methodolomes  havp  cm»citKt  _ : _ ,  .  • 


- w  «*wuiy.  release  integration  has  sigmficantly  reduced  cycle  time  and 

pr0C€SSl^lthe  verified  desi§n  data.  Industry  standardization  of  MCM  and 
“  wformatlon  f°™ats  will  further  improve  release  and  processability  of  data  from  a  wider 
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2.5  Framework 


The  framework  activity  m  the  contract  was  identified  because  of  the  recognized  importance  of  data 
integrity  and  process  management  in  assuring  first  pass  design  and  release  success.  This  activity 
also  recognized  that  the  design  and  release  process,  at  the  beginning  of  the  contract,  operated  on 
information  from  a  number  of  different  sources.  From  the  custom  MCM  perspective,  many  steps 
in  the  process  were  performed  using  manual  (data  transfers  and  paper  driven)  point  tools.  The 
mtoit  was  to  use  some  framework  to  begin  to  link  and  automate  the  steps  of  the  process.  By 
linking  and  automating  pieces  of  the  process,  it  would  not  only  run  faster  but  reduce  errors  and 
learning  curves  associated  with  staffing  these  processes. 

2.5.1  Introduction 

Utilizing  a  framework  was  an  activity  that  needed  evaluation  because  of  the  benefit  game  expected 
from  integration.  These  benefits  are  enumerated  below:  f 

1 .  Framework  reduces  cost  and  turn-around  time 
Reduced  design  cycle  time  implies  reduced  cost  by: 

•  Reducing  design  system  iterations  -  a  framework  keeps  better  control  of  design  data. 

•  Sharing  data  between  tools. 

•  Providing  a  cohesive  user  interface. 

•  Providing  a  consistent  design  environment. 

•  Providing  control  of  the  design  process  -  the  order  of  design  steps. 

The  above  reasons  are  most  notable  for  cycle  time  and  cost  reduction  for  less  experienced 

personnel.  They  are  more  debatable  by  experts  who  desire  more  freedom  for  special  case 
conditions. 

•  Initiating  foreground  or  background  jobs  on  VM  or  MVS  from  the  work-station  -  data 

is  passed  between  AIX  and  the  host.  The  design  process  is  managed  from  the  system 
level,  not  the  lower  tool  level. 

•  Providing  audit  control. 

These  can  affect  cycle  time  by  helping  personnel  with  general  tasks  of  data  transfer  and  project 
status  which  make  success  easier  to  achieve. 

2.  Framework  increases  quality  of  product. 

When  the  design  cycle  is  complete,  a  quality  product  is  assured  because: 

•  A  framework  maintains  design  integrity. 

•  The  framework  s  database  manager  is  used,  not  individual  file  structures. 

•  The  correct  set  of  hardware  design  rules  and  releases  of  software  tools  is  used. 

•  The  designer  is  no  longer  using  multiple  stand-alone  ("point")  tools  with  individual 

databases. 

•  The  designer  is  assured  that  all  design  steps  have  run  successfully  -  audit  control  over 

the  methodology. 

•  All  design  data  for  all  tools  is  stored  in  a  single  database  controlled  by  the  framework. 
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The  quality  aspects  of  framework  are  again  aimed  at  reducing  opportunity  for  error.  In  this  sense, 
it  allows  a  reduction  in  the  distribution  of  cycle  time  and  errors  between  ’experts’  and  ’novices’  in 
specific  domains. 

Initial  work  involved  investigating  Framework  capability  and  estimating  efforts  and  pay  back 
associated  with  the  integration  of  the  design  and  release  process  in  a  framework. 

2.5.1.1  Design  and  Release  Environment. 

The  IBM  tool  set  consists  of  design  and  release  tools  from  Cadence  and  IBM.  These  include 
Allegro,  IGS2,  USC,  a  number  of  host  based  electrical  and  thermal  analysis  tools,  host  based 
documentation  and  manufacturing  release  tools.  In  managing  data  integrity  and  process  control, 
both  design  data  management  (DDM)  and  process  management  (PM)  is  necessary. 

2.5.1.2  Ideal  Framework  Characteristics 

Characteristics  of  an  robust  framework  are  listed  in  Figure  2.5-1  and  illustrate  the  detail  to  be 
considered  in  developing  an  integrated  process. 

2.5.1.3  Framework  Evaluations 

A  requirements  and  architecture  document  was  created  which  defined  an  ideal  description  of  an 
integrated  design  system.  This  was  written  relative  to  IBM  ProFrame  capabilities  and  CFI  2.0 
extensions.  Then  alternatives  were  reviewed  against  that  definition.  There  were  three  areas  to 
consider: 

1 .  Framework  capabilities  and  extendibility 

2.  Process  flexibility  and  maintainability  in  the  Framework 

3 .  Maximizing  industry  benefit  from  the  integration  activity 

Conclusions  drawn  from  this  activity  were  used  to  determine  an  integration  approach  which  would 
be  demonstrable.  This  is  described  below. 

2.5.2  Framework  Evalutaion 

Mentor  Graphics,  Cadence,  and  IBM  Framework  options  were  evaluated.  Most  of  the  effort 
focused  on  the  IBM  and  Cadence  options  since  no  native  Mentor  Graphics  point  tools  were  part  of 
the  existing  design  or  release  process  (i.e  choosing  the  Mentor  Graphics  framework  would  only 
complicate  the  effort  since  no  existing  tools  would  be  integrated  naturally). 

Cadence  had  two  framework  environments,  ValidFrame  and  Design  Framework  2.  Some 
confusion  existed  as  to  which  was  appropriate  for  the  larger  integration  objective  and  which 
framework  operated  with  the  Allegro  tool  and  which  would  ultimately  be  supported  by  Cadence. 

ValidFrame  had  process  management  capability  with  its  two  components  PMAN  (process 
manager)  and  CMAN  (communication  manager).  PMAN  supported  launching  SKILL  programs  so 
additional  flexibility  was  possible.  (SKILL  being  a  programming  language  that  can  create 
functions  for  a  variety  of  special  requirements  e.g.  DDM).  Additionally,  a  new  Cadence  product 
was  announced,  Teamwork  Design  Manager,  that  integrated  much  of  the  function  needed  to 
address  process  and  data  management.  The  Card  design  environment  had  used  the  concepts  of 
Teamwork  Design  manager  in  a  project  called  ACE  for  internal  printed  circuit  board  release  at 
some  IBM  sites.  Design  Framework  2  was  developed  mainly  for  chip  design  software. 

IBM  ProFrame  has  both  PM  and  DDM  capabilities  and  therefore  looked  like  the  most 
advantageous  and  extendible  approach.  The  drawback  of  this  framework  was  that  Allegro  and 
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other  IBM  tools  would  have  to  be  encapsulated  in  order  to  allow  communication  to  occur.  Another 
drawback  was  the  fact  that  there  was  a  very  small  installed  base  of  this  framework  so  few  others 
would  benefit  from  activity  in  this  area. 

2.5.2. 1  Overview  of  the  Tool  Integration  Process 

Process  integration  should  follow  the  CFI  definition  of  the  steps  involved  in  tool  encapsulation  and 
involve  specific  personnel  skills  defined  below. 

The  following  is  the  CFI  definition  of  the  five  steps  involved  in  the  Tool  Encapsulation  Process: 

•  Selecting  the  Tools. 

*  Tools  are  selected  by  the  process  developer. 

*  Decide  the  sequence,  conditions,  and  relationships  among  tools  in  the  process. 

•  Characterizing  the  Tools. 

The  process  developer  examines  the  tool's  peripherals: 

*  Input/output  data/files. 

*  Invocation  constructs. 

*  Return  codes. 

*  Message/error  logs. 

•  Defining  the  Design  Methodology. 

The  process  developer  defines  the  design  methodology,  including: 

*  Data  hierarchy. 

*  Data  flow. 

*  Invocation  parameters. 

*  Enforced  process  flow. 

•  Generating  Encapsulation  Wrappers. 

The  tool  integrator  writes  the  wrappers. 

•  Registering  the  Tool  to  the  Framework. 

The  tool  integrator  registers  the  tool. 

As  stated  in  the  IBM  ProFrame  "Tool  Encapsulation  User  Guide",  the  following  personnel  are 
required  in  order  to  encapsulate  a  tool  for  use  in  a  process: 

•  Process  Developer  -  Lead  designers  who  combine  tools  to  form  a  design  methodology 

(collection  of  tools)  used  by  designers. 

•  Tool  Developer  --  Write  programs  used  by  design  engineers. 

•  Tool  Integrator  --  Implement,  install,  and  customize  the  design  methodology;  write 

wrappers,  programs,  shell  scripts,  or  command  scripts. 

•  Framework  Developer  —  Software  engineers  who  write  and  enhance  CAD  framework 

software. 

•  Designer  —  Ultimate  end-user;  execute  CAD  tools  in  a  formal  or  informal  design 

methodology  to  create  electronic  designs. 


2-91 


CFI  2.0  Compliant  —  Message  Classes  and  Interpreters 
Introduction 
Definitions 
DBMS  Requirements 
Library  System  Requirements 
General  Requirements 
Check-Out  Functions 
Check-In  Functions 
Add  Functions 
File  Promotion  Functions 

Library  System  Requirements  Not  Currently  Planned 
IBM  Framework 
DBMS  —  Design  Environment 
DBMS  —  Direct  Release  Environment 
Data  Repository 
Types  of  Functions 
Tool  Encapsulation 
IBM  Framework  Components 
Design  Control  (Version  Management) 

Controlling  Design  Data 
Framework  Utilities  Provided 
Framework  to  Framework  Integration 
CFI  2.0  Enhancements  to  IBM  Framework 
CFI  1.0  Features 
CFI  2.0  Enhancements 
CFI  2.0  —  Design  Representation 
CFI  2.0  —  Design  Data  Management 
CFI  2.0  —  Tool  Construction 
CFI  2.0  —  Tool  Execution 
CFI  2.0  —  Framework  Administration 
Security,  Backup,  Recovery 
Future  Direction 

CFI  Framework  Backplane  Example 
IBM  Framework  Components  and  Interfaces 
Design  Control  Structure 
Methodology  Management  Editor 
High  Level  Process 
Low  Level  Process 

Data  Manipulation  in  IBM  Framework 
CFI  ITC  Message  Server  Model 
Inter-Framework  Communications 
Framework  to  Framework  Standard 

Figure  2.5-1:  Framework  Requirements  Example 
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2.5.2.2  Process  Flexibility  and  Maintainability  in  the  Framework 

Flexibility  can  be  evaluated  two  ways.  First,  flexibility  can  be  viewed  as  Framework  flexibility, 
i.e.  by  the  way  and  degree  to  which  a  process  can  be  implemented.  Secondly,  flexibility  can  be 
viewed  as  resource  flexibility,  i.e.  the  resources  required  by  a  business  to  implement  and  maintain 
its  tools.  The  second  approach  recognizes  that  to  develop  and  manage  a  process  within  a 
Framework  requires  skills. 

Flexibility  was  initially  looked  at  from  the  point  of  view  of  which  Framework  allows  the  greatest 
amount  of  capability  or  variation  in  tools  and  steps  within  the  process.  The  IBM  ProFrame 
environment  seemed  to  fit  this  description. 

Resource  flexibility  asks  the  question,  ‘How  much  effort  does  it  take  to  establish  and  maintain  a 
skill  base  for  the  required  activity?’  From  this  light,  the  framework  that  was  the  simplest  to  work 
with  and  the  most  consistent  with  other  knowledge  needed  to  perform  business  functions  should  be 
considered.  Cadence  Allegro  SKILL  and  ValidFrame  knowledge  is  of  value  to  general  Cadence 
users  and  AMPLE  knowledge  is  beneficial  to  Mentor  Graphics  users  so  these  seemed  to  be  the 
most  flexible  for  staffing.  Further  investigation  also  showed  that  most  functions  could  be  defined 
with  SKILL  and  even  the  cases  which  required  data  transfers  between  many  tools  could  be  handled 
with  standard  data  transfer  functions.  Similarly,  AMPLE  could  provide  the  same  integration 
capability  for  the  Mentor  Graphics  environment.  For  the  case  of  Release,  the  similar  capability  was 
with  the  REXX  programming  language  running  with  a  background  VM  processor  (TOOLSRUN 
account).  Release  functions  operated  in  host  environments,  and  REXX  was  an  existing  release 
personnel  skill  base. 

Maintainability  needed  to  be  considered  too.  This  includes  questions  as  to  how  much  does  it  cost 
to  maintain  the  skill  base  for  ongoing  support  and  extensions  to  processes  developed.  The  business 
must  be  able  to  migrate  to  new  tools  and  processes  as  technology  and  tools  progress.  This  seemed 
most  supportable  by  implementations  in  software  formats  that  are  useful  for  design  and  release 
personnel  to  know. 

2.5.2.3  Maximizing  Industry  Benefit  from  the  Integration  Activity 

Maximizing  the  industry  benefit  was  one  of  the  objectives  of  the  whole  ASEM  program.  In  the 
case  of  framework,  this  came  down  to  the  following  criteria: 

1 .  How  can  this  activity  be  utilized  by  the  largest  design  community? 

2.  How  can  the  money  for  this  activity  be  best  spent? 

When  looked  at  in  this  light,  two  facts  became  obvious.  One  is  that  the  way  to  maximize  the 
potential  number  of  users  would  be  to  include  as  much  as  possible  of  this  effort  within  the  Design 
Kit  that  was  intended  for  distribution.  The  second  fact  was  that  the  minimum  software  investment 
option  should  be  selected  so  that  a  larger  audience  would  be  able  to  reap  the  benefits.  In  light  of 
design  kits  though,  a  process  would  be  beneficial  in  each  of  the  tool  sets  native  environment,  hence 
a  process  in  the  Mentor  Graphics  tool  set,  and  one  for  the  Cadence  tool  set. 

Release  tools  are  foundry  specific,  so  no  apparent  industry  value  could  be  gained  beyond  the 
reduced  NRE  associated  with  utilizing  the  improved  process. 
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Lastly,  a  number  of  encapsulation  wrappers  would  be  required  to  integrate  the  design  and  release 
tools  into  a  single  framework. 

2.5.3  Implementation 

Viewing  this  information  from  the  three  perspectives  above,  the  most  effective  implementation 
seemed  to  be  the  simplest  approach.  Use  of  standard  Cadence  and  Mentor  Graphics  framework 
and  extension  language  capabilities  for  design  integration  and  automation  and  use  of  host 
programming  language  for  the  release  integration  and  automation.  With  this  choice,  there  were  no 
message  classes  that  were  needed  for  the  IBM  User  Framewoik.  Communication  between  design 
and  release  did  not  seem  critical  because  it’s  a  one  time  transaction  and  did  not  need  tight 
integration  for  improved  effectiveness.  Communication  between  Design  and  Release  frameworks 
was  handled  by  standard  data  transfer  commands  (ftp  from  workstations  to  mainframe,  sendfile 
and  XMIT  between  mainframe  environments).  This  allowed  both  design  and  release  to  evolve  in  a 
way  that  was  most  effective  for  the  respective  starting  points.  The  details  are  described  below. 

2.5.3.1  F ramework  Integration  of  Direct  Release 

As  described  in  the  Direct  Release  Section,  the  original  approach  was  modified  to  an  evolutionary 
strategy  to  eventually  support  release  in  a  workstation  environment.  The  integration  utilized 
existing  tools  and  skills  within  the  IBM  organization.  The  department  responsible  for  processing 
the  design  data  understood  the  point  tools  and  how  to  integrate  tools  in  a  host  environment  using 
the  REXX  language  that  is  portable  between  mainframe  and  workstation  environments.  Under  the 
title  of  BRX  ,  menus  and  interfaces  to  design  data  were  prototyped,  refined,  and  used  for  the  daily 
processing  of  design  data.  This  development  started  at  the  post-processors  and  moved 
progressively  upstream  to  the  design  documentation  requirements  of  the  release  process. 

The  following  sample  of  BRX  Menus  are  provided  to  demonstrate  the  function  of  the  BRX  system. 
Initial  menu: 
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F3=Exit  F12=Cancel  | 

^ien  ^r?ss  Section  *s  selected  from  the  main  menu,  the  following  appears: 
PRODUCT  ZUMBRO,  CROSS  SECTION. 

LAYER  FUNCTION  (BL  BS  Bn  Gn  RIT  Rn  TS  Tn  Vn  Xn  Yn 
Mn) 

1  TS  VI 

2  V2 

3  V3 

4  XI 

5  X2 

6  V4 

7  V5 

8  X3 

9  X4 

10  V6 

11  V7 

12  V8 

13  BS 


F2-Edit  F3=Exit  F7=Bkwd  F8=Fwd  F12=Cancel _ 

^en  Metal  Masks  is  selected  from  the  main  menu,  the  following  appears: 
PRODUCT  ZUMBRO,  METAL  MASK  SPECS. 

_  Metal  Mask  GL1  Summaries 
_  Metal  Mask  GL1  Images 
_  Metal  Mask  Functional  Indexes 
_  Metal  Mask  Part  Numbers 
_  Metal  Mask  GL1  Levels 
_  Metal  Mask  Attributes 
_  Metal  Mask  Feature  Dimensions 
_  Metal  Mask  Post  Processing  Jobs 

F3=Exit  F12=Cancel 
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When  Metal  Mask  Feature  Dimensions  is  selected  for  Layer  1  from  the  Metal  Masks  menu,  the 

following  appears:  _ 

Use  PF2  if  you  want  to  edit. 

PRODUCT  ZUMBRO,  METAL  MASK  FEATURE  DIMENSIONS  for  MFI V1Q. 


GL1 

MASK 

MASK  WINDAGE  ARTW 

ARTW 

MAXSEG 

IMAGE 

LEVEL 

FIRED 

GREEN 

REF 

GREEN 

GREEN 

REF 

FIRED 

TAB 

B-LIN 

(in) 

(in) 

(Y/N) 

(in) 

(in) 

(Y/N) 

(mm) 

(mm) 

9-RLS 10001 

.0039 

.0038 

N 

-.0018 

.0020 

N 

0.56 

C-PAD 

(6  7) 

.0049 

.0060 

N 

-.0021 

.0039 

N 

D-LIN 

8-RLS20001 

.0049 

.0059 

Y 

+.0000 

.0059 

Y 

5.00 

2.53.2  Framework  Integration  of  Design 

ValidFrame’s  PMAN  and  CMAN  were  used  as  the  global  process  management  tools.  Automation 
of  individual  steps  were  achieved  through  implementation  of  functions  in  SKILL  which  became 
available  in  the  Allegro  environment  in  the  middle  of  the  contract. 

An  initial  process  flow  was  established  in  the  PMAN  as  shown  in  Figure  2.5-2.  This  built  on  a 
two  tier  process  flow,  one  for  the  conceptual  through  physical  design  flow  and  a  more  detailed 
layer  for  the  specific  physical  design  flow.  Extensions  were  projected  for  physical  design  entry 
where  completed  physical  designs  get  transformed  into  foundry  manufacturable  data  formats  and 
are  rechecked  against  manufacturability  requirements.  Process  steps  are  initiated  by  text  buttons, 
data  entry  is  accomplished  with  SKILL  forms,  process  automation  is  accomplished  by  SKILL 
routines. 


2.5.3.3  Benchmarks 

Cycle  times  have  been  reduced  by  more  than  50%  in  the  integrated  release  environment.  The 
reduction  is  the  result  of  elimination  of  numerical  calculation,  elimination  of  redundant  data  entry, 
elimination  of  rework  due  to  errors,  and  improved  job  completion  status  verification. 

Specific  design  cycle  time  reductions  have  not  been  measured  but  the  integrated  design 
environment  is  much  simpler  for  a  new  user.  Experienced  users  are  not  expected  to  benefit  in 
terms  of  cycle  time,  but  their  susceptibility  to  typing  errors  is  reduced  by  the  visual  interface  and 
they  are  prompted  for  typical  data  rather  than  having  to  rely  on  their  experience. 
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2.5.4  Conclusions 


exch^l  lX  ere  ^  n0  additlonal  Rework  features  needed  documentation  and  data 

^  demonstrated‘  Process  management  in  framework 
wronments  is  justifiable  to  the  extent  that  business  conditions  can  afford  the  implementation  and 
maintenance  of  the  process.  Ibis  is  dictated  by  the  skills  required  for  process  management  relative 
to  those  required  for  general  business  functions.  Typically  the  business  case  is^nhSced  if 
“f, °“erl.Can  ^tdirectlyfrom  integration,  such  as  when  integration  activities  compliment 
ce  offerings  like  design  kits.  Significant  benefits  are  expected  in  the  areas  of  quality  and 
process  learning  curves  within  framework  integrated  processes.  Quality  is  measured  by  the 

LC^^t^Zf^TofmanypracesscyclK' 

a,PrOCeS1S  is  ™plemented  is  **  tools  are  chosen,  wrappers  (encapsulation  programs)  are 
established  to  make  the  tool  available  for  use,  and  a  methodology  is  described  and  implemented. 
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3.0  MCM  TEST 


Overview 

Providing  high-quality  MCMs  at  a  reasonable  cost  can  be  a  challenge  even  in  a  captive  environment,  during 
which  both  the  chip  and  MCM  designs  are  within  a  company's  control.  With  an  OEM  MCM  foundiy, 
however,  the  test  environment  becomes  more  complex,  as  the  customer  (company  ordering  the  MCM),  may 
not  be  in  a  position  to  control  or  even  divulge  the  details  of  the  die  being  used,  and  be  only  willing  to  expend 
minimal  funds  to  ensure  adequately  tested  product.  As  a  customer-driven  facility,  the  foundry  must  cater  its 
test  strategy  to  the  customer's  priorities.  ARPA  has  set  a  number  of  specific  goals  for  the  ASEM  program 
which  are  detailed  in  reference  [1]. 

Collectively,  cy  cle  time  and  cost  goals  can  only  be  met  if  all  testing  operations  are  extremely  efficient,  well- 
defined,  and  non-duplicative,  while  flexible  enough  to  serve  a  variety  of  MCM  products.  To  meet  cycle  time 
and  cost  goals,  work  was  undertaken  contract  subsection:  2. 1 . 1 . 1 .4.  The  task  is  described  as  development  of 
a  testability  strategy  and  guideline  which  will  support  entry  points  into  the  IBM  foundry  at  various  design 
levels.  One  result  of  this  work  is  a  document  titled,  "ASEM  Report  on  Testability  Strategy  and  Guidelines," 
ARPA  ASEM  Document  no.  CLIN0002AH,  7/3 1/93  [2]  and  was  delivered  to  ARPA  on  7/3 1/94.  The 
document  contains  a  proposed  strategy  for  meeting  the  ARPA  ASEM  goals  for  turn  around  time  and  cost 
reduction.  The  following  report  expands  on  the  Strategy  and  Guidelines  document  and  details  the  test 
environment,  test  methodology,  implementation  of  the  proposed  test  strategy  and  presents  the  results  of 
testing  two  different  application  demonstration  vehicles.  The  test  strategy  was  implemented  largely 
unchanged  from  the  proposed  strategy  with  the  addition  of  test  database  verification  procedures. 

The  approach  used  to  meet  the  goals  for  TAT  and  cost  was  to  develop  a  strategy  which  was  appropriate  to 
the  business  and  customer  environment  with  respect  to  design  ownership  and  tasks.  The  second  element  of 
the  approach  to  meeting  our  goals  was  to  install  appropriate  tooling  and  business  processes  to  support  the 
selected  test  methodology.  The  third  element  in  our  approach  was  to  benchmark  progress  in  lowering  our 
TAT  and  NRE  cost  by  monitoring  the  effort  spent  in  performing  test  on  real  MCMs.  The  results  of  the 
benchmarking  would  verify  that  the  implemented  test  strategy  was  in  fact  producing  lowered  TAT  and  costs. 
The  use  of  actual  application  test  vehicles  also  facilitates  debug  of  procedures  and  identifies  areas  requiring 
extra  attention. 

Section  Organization 

The  Module  Test  section  of  the  report  is  presented  starting  with  a  brief  description  of  the  challenges  to  test 
and  the  approaches  taken  to  meet  the  Foundiy  project  goals. 

•  Section  3. 1  describes  the  MCM  test  environment  which  includes  a  breakdown  of  the  various  types  of 
tests  required  and  issues  associated  with  each  test  type. 

•  Section  3.2,  Test  Methodology,  describes  the  foundiy  low  cost  and  quick  turn  around  time  test 
methodology.  It  includes  the  reasoning  for  the  selection  of  the  chosen  test  methodology  as  well  as  a 
description  of  various  ramifications  implied  for  support  infrastructure  and  test  equipment. 

•  Section  3.3  is  the  implementation  of  the  test  methodology.  It  includes  descriptions  of  the  hardware 
tools,  software  tools,  design  for  test  and  test  database  content  which  are  part  of  the  employed 
methodology. 

•  Section  3.4,  Known  Good  Die,  presents  the  strategy  and  implementation  of  using  temporary  chip 
attach  technology  using  single  chip  modules  for  production  of  known  good  and  burned  in  die. 
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Section  3.5,  details  data  integrity  problems  experienced  during  the  execution  of  the  application 
demonstration  MCM  programs  and  presents  a  i 


Section  3.6  summarizes  results  from  two  application  demonstration  MCM  case  studies  and  presents 
the  result  of  our  benchmarking  activity. 

Section  3.7  presents  key  conclusions  concerning  each  area  of  the  MCM  test  report. 


Some  material  in  each  of  the  sections  of  the  MCM  Test  report  overlaps  with  other  sections  of  the  test  report. 
This  was  done  to  make  each  section  more  readable,  hence  minimiring  the  need  to  reference  other  sections  of 
the  report. 
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3.1  TEST  ENVIRONMENT 


3.1.1  MCM  Testing  Challenge 


The  key  to  efficient  and  effective  testing  is  the  development  of  a  test  strategy  which  clearly  defines  what  tests 
should  be  applied  at  each  stage  of  the  manufacturing  process.  The  goal  of  the  test  strategy  is  to  minimis 
product  life-cycle  costs,  where  these  costs  are  defined  as  the  sum  of  development  cost,  production  cost,  and 
imperfect  test"  cost.  Development  cost  is  the  non-recurring  (volume-independent)  cost  associated  with 
generating  the  tests,  assessing  their  quality  (e.g.,  fault-simulation),  implementing  tests  on  the  tester,  and  any 
unique  hardware  requirements  necessaiy  for  test  application  (such  as  test  fixturing).  Production  cost  is  the 
recurring  (volume-dependent)  cost  of  testing  the  MCMs,  which  includes  equipment  cost,  operating  cost  and 
support  cost.  "Imperfect  test"  cost  is  the  cost  associated  with  deferring  to  higher  packaging  levels  the 
detection  of  defective  product  which  is  generally  a  more  costly  practice  than  detecting  defective  parts  at  a 
lower  level  of  packaging.  An  optimal  strategy  balances  each  of  these  three  cost  elements  at  each  test  stage  so 
that  the  total  life-cycle  cost  is  minimized,  and  placement  of  undue  emphasis  on  one  particular  aspect  is 
avoided.  For  example,  there  may  well  be  fault  categories  which  are  either  so  unlikely  or  so  expensive  to 
detect  at  a  given  package  level,  that  it  is  cost  effective  to  assume  that  they  will  be  detected  later  in  the 
production  scheme. 


One  approach  used  to  meet  the  MCM  test  challenge  for  developing  an  optimum  strategy  was  developed  in 
[3],  and  was  applied  for  a  captive  MCM  production  facility  in  [4],  In  the  foundiy  environment,  however  this 
approach  must  be  altered  to  reflect  the  fact  that  the  foundry  itself  can  only  control  portions  of  the  necessary 
manufacturing  tests,  and  should  incorporate  the  customer's  definition  of  cost  elements,  especially  when  it 

comes  to  imperfect  test  cost.  These  particular  aspects  are  common  to  all  MCM  foundries,  and  have  been 
addressed  in  [5,6], 


3.1.2  MCM  Test  Categories 


In  a  generic  view  of  the  MCM  manufacturing  flow,  there  are  five  test  categories  which  most  likely  will  be 
applied  as  shown  in  Figure  3-1  and  described  below. 


3.1 .2.1  Die  Test 

Chip  level  test  is  the  most  critical  juncture  of  the  test  flow.  Typically,  the  yield  from  this  step  is  dramatically 
lower  than  elsewhere  m  the  manufacturing  process.  Thus,  the  likelihood  that  untested  circuitry  will  in  realitv 
e  defective  is  an  important  concern.  Additionally,  this  step  represents  the  minimum  investment  in  materials 
and  labor,  and  therefore  is  the  ideal  point  at  which  defective  ICs  should  be  weeded  out.  Unfortunately,  the 
electrical  environment  during  wafer  probing  represents  the  worst  conditions  that  the  IC  will  encounter 
Probes  provide  high  capacitive  loading,  often  an  order  of  magnitude  higher  than  seen  at  the  system  level. 
Similarly,  the  environment  is  highly  inductive,  creating  a  problem  when  today's  high  speed,  high  current 
primary  outputs  are  switching.  This  problem  is  especially  acute  as  the  number  of  I/Os  increase.  These 
factors  combine  to  raise  the  real  potential  that  perfectly  good  ICs  will  fail  wafer  test. 
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When  the  ICs  are  destined  for  a  Single  Chip  Module  (SCM),  it  is  possible  to  accept  a  less  rigorous  test  at  the 
wafer  level  and  assume  that  some  classes  of  defective  chips  will  be  detected  during  single  rhip  module  test.  If 
the  IC  turns  out  to  be  defective,  the  cost  impact  is  minimal,  as  the  SCM  is  simply  discarded  and  all  that  is  lost 
is  the  cost  of  assembly  plus  carrier  cost. 


Ship 


Figure  3-1 :  MCM  Manufacturing  Test  Process  Flow 


Reduced  testmg  at  die  wafer  level  can  be  more  of  a  problem  for  MCM  testing,  as  identifying  which  of  many 
chips  on  the  MCM  is  defective  can  represent  a  significant  cost,  plus  the  cost  associated  with  rework  and  the 
potential  that  the  defect  will  not  be  adequately  diagnosed,  thereby  placing  the  entire  MCM  at  risk,  a  major 
cost.  In  some  technologies,  such  as  "chips-first"  MCM  assembly  techniques,  rework  itself  may  be  so 
expensive  as  to  justify  skipping  rework  altogether,  which  inherently  adds  to  the  cost  of  providing  good 
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MCMs.  To  address  the  need  for  high  quality  die,  to  be  mounted  on  the  MCM,  many  temporary-attach 
methods  have  been  developed  [23],  These  approaches  mount  diced  chips  onto  single  chip  carriers  which  can 
then  be  subjected  to  intensive  module  screens  not  possible  at  the  wafer  level,  and  may  include  bum-in.  Die 

surviving  such  tests  are  Known  Good  Die  (KGD)  and  are  removed  from  the  carrier  and  mounted  onto  the 
MCM. 

3.1. 2.2  Substrate  Test 

Testing  of  the  substrate,  onto  which  the  chips  will  be  mounted,  is  an  essential  part  of  the  manufacturing 
process.  Such  earners  can  contain  a  large  number  of  wiring  layers,  and  high  wiring  densities.  In  addition  to 
in-process  measurements,  an  open/shorts  test  is  routinely  applied  to  all  interconnections,  using  either  a  singly 
or  dual  probe.  As  these  tests  are  easily  determined  from  the  physical  layout,  they  can  be  generated  directly  by 
the  substrate  manufacturer,  from  manufacturing  data. 

3.1. 2.3  MCM  Interconnect  Test 

The  interconnect  test  is  the  backbone  of  the  MCM  test  profile.  It  is  used  to  assure  proper  electrical  continuity 
between  all  MCM  primary  inputs/outputs  and  the  mounted  chips,  and  on  all  connections  between  mounted 
chips.  In  the  process,  all  interconnecting  mechanisms  including  bonding,  soldering,  and  the  complete 
substrate  are  tested.  This  test  is  key,  as  it,  of  all  the  MCM  tests,  most  directly  verifies  that  the  assembly 
operations  were  performed  properly.  On  the  other  hand,  the  remaining  tests  tend  to  verify  that  damage  to 
presumably  good  components  has  not  occurred,  or  to  apply  tests  that  could  not  practically  be  applied  at  prior 
steps  in  the  manufacturing  process. 

3.1 .2.4  Chip  Internal  Test 

The  chip  internal  test  verifies  that  logic  circuitiy  that  feeds  only  other  circuitry  within  the  chip  itself  is  tested. 
Ideally,  such  circuitry  has  already  been  tested  during  wafer  and/or  bare  die  test.  There  are  incentives, 
however,  for  repeating  this  test.  First,  it  is  possible  that  the  assembly  process,  which  can  include  subjecting 
Uie  die  to  relatively  high  temperatures,  may  induce  a  metal  break  or  other  continuity  problems.  Secondly,  the 
improved  electeical  environment  at  the  module  level  vs.  wafer  probe  can  permit  higher  speed  tests  to  be 
applied,  isolating  marginal  die.  Thirdly,  high  reliability  screens,  such  as  temperature  cycling,  bum-in,  and 
testing  over  wide  temperature  ranges  can  surface  defects  missed  in  prior  testing.  Given  the  contrasting 
objectives  between  the  interconnect  and  chip  internal  tests,  different  test  strategies  may  well  apply.  It  is  not  a 
given,  however,  that  the  chip  logic  can  easily  be  segregated  as  internal  vs.  external  logic.  A  variety  of 
schemes  have  been  proposed  to  permit  this  separation.  The  most  popular  approach  is  through  conformance 
to  IEEE  Standard  1 149. 1.  This  standard  [7],  known  often  by  its  originating  group,  the  Joint  Test  and  Action 
Oroup  (JTAG),  was  originally  designed  to  address  the  problems  associated  with  board  level  test.  It  defines  a 
standardized  test  port  interface  and  communications  structure.  The  primary  focus  of  this  methodology  is  to 
ease  the  generation  of  board  interconnect  tests  (wire  tests),  by  providing  latches  at  the  boundary  of  each 
board  component.  These  latches  are  then  serialized  (daisy  chained)  to  form  a  single  string  that  is  scanable  via 
the  4  pm  port  on  each  chip.  Additionally,  an  optional  test  mode  is  defined  that  enables  individual  component 
self  test.  While  other  approaches  exist,  such  as  [4],  1 149. 1  has  developed  broad  support,  and,  when 
implemented  on  a  bare  die,  enhances  that  chip's  salability. 

3.1. 2.5  MCM  Functional  Test 

MCM  functional  test  is  an  at-speed  test  which  is  primarily  used  to  screen  for  parametric  variations  in  die 
and/or  substrates  which  lead  to  out  of  specification  MCM  performance.  There  are  also  benefits  in  applying  a 
function-oriented  test  which  mirrors  actual  application  as  opposed  to  the  fault-oriented  tests  automatically 
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generated  via  EDA  systems  [8].  These  tests  can  exercise  clocking  circuitry  essential  for  maintaining  high 
speed  performance  which,  due  to  its  timing  nature,  must  be  bypassed  during  Design-For-Testability  (DFT) 
approaches  such  as  scan-based  DFT  and  1 149. 1.  A  less  compelling  incentive,  but  a  customer  consideration 
nevertheless,  is  the  desire  to  verify  that  the  MCM  actually  performs  its  intended  function.  In  today's 
structured  design  development  environments,  design  verification  via  software  simulators  along  with  static 
analysis  systems  should  be  the  prime  mechanism  for  ensuring  that  the  manufactured  component  performs  as 
expected.  Unquestionably,  prototype  hardware  will  be  rigorously  exercised  to  provide  functionality 
verification,  but  this  is  a  development,  not  MCM  manufacturing,  process. 

Finally,  as  opposed  to  AC  exercise,  or  'warm  and  fuzzy'  verification,  the  MCM  functional  test  can  represent 
the  only  test  available.  The  MCM  customer  may,  for  instance,  be  simply  repackaging  a  card  or  board 
application  into  an  MCM.  This  customer  does  not  know,  or  necessarily  care,  about  the  details  of  the  chips 
mounted  or  contained  within.  The  imbedded  chips  may  not  contain  any  DFT  approaches,  thus  precluding 
automatic  test  generation.  Additionally,  the  customer  may  not  be  willing  to  expend  the  development  cost 
associated  with  the  above  alternative  test  methods. 

There  are  two  major  hurdles  to  functional  testing.  First,  it  is  veiy  difficult  to  assess  the  quality  of  such  tests. 
The  trivial  example  of  the  8  input  OR  block,  which  requires  9  tests  to  stuck-fault  test  vs.  256  tests  for 
functional  verification,  highlights  this  dilemma.  The  importance  of  quality  assessment  depends  upon  the 
objectives  for  the  test.  In  'warm  and  fuzzy'  mode,  considerably  fewer  tests  are  necessary  than  in  the  case 
where  the  functional  tests  are  the  only  ones  applied.  In  any  case,  some  measurable  sense  of  'coverage'  is 
necessary  to  define  pattern  completeness.  This  evaluation  can  range  from  decision  path  tracing  from  a  flow 
diagram,  to  simply  counting  node  toggling 

The  second  hurdle  to  functional  testing  is  the  inherent  difficulty  of  diagnosis.  DFT  test  patterns  typically 
drive  from  one  latch  to  another,  thus  limiting  the  location  of  the  defect  that  could  induce  an  observed  failure. 
Functional  patterns,  with  their  broad  band-width  application,  typically  cycle  through  a  number  of  register 
banks  before  the  problem  is  observable,  thus  dramatically  increasing  the  number  of  circuits  which  may  be  the 
weak  link.  When  functional  patterns  are  the  prime  technique  for  identifying  manufacturing  defects,  this 
difficulty  in  diagnosis  can  lead  to  (a)  more  time-consuming,  labor-intensive  diagnostic  efforts,  and  (b)  a 
higher  potential  that  repair/rework  can  not  be  performed,  thus  requiring  that  the  failing  MCM  be  scrapped. 
Both  of  these  can  significantly  increase  product  cost.  Another  snag  associated  with  functional  patterns  is  that 
the  tester  may  have  difficulty  in  applying  the  tests  exactly  as  specified.  Tester  patterns  are  based  upon  fixed 
cycles  during  which,  ideally,  input  stimuli  and  output  strobes  occur  at  regular  intervals.  More  advanced 
testers  are  more  flexible  in  providing  a  variety  of  timings  for  a  single  I/O,  but  even  these  multi-million  dollar 
testers  run  out  of  steam  eventually.  Usage  of  such  testers  will  in  turn  increase  the  production  cost,  and  may 
cause  the  functional-test-only  approach,  which  has  traditionally  appeared  to  be  the  low-cost  methodology,  to 
be  the  most  expensive  alternative,  especially  as  production  quantities  and  reliability  goals  increase. 

3.1.3  Captive  versus  OEM  Foundry  Test  Environment 

In  the  captive  product  environmental,  all  of  the  previously  described  test  environments  are  within  the  control 
of  the  manufacturer,  and  can  thus  be  coordinated  and  controlled.  In  the  foundry  environment,  however,  this  is 
not  the  case.  Typically,  the  die  are  manufactured  by  another  supplier,  who  may  well  consider  that  the  logic 
internal  details  and  tests  to  be  applied  are  proprietary.  While  the  die  supplier  can  acknowledge  that  bum-in 
was  or  was  not  performed,  the  actual  quality  of  the  tests  applied  (a  more  significant  aspect)  may  not  be 
provided.  Lack  of  details  concerning  the  die,  can  preclude  development  of  an  MCM  interconnect  test,  unless 
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311  aeeepted  standard,  such  as  1 149. 1  has  been  used.  Generation  of  a  chip  internal  test  is  even  more  unlikely 
without  knowledge  of  either  the  on-chip  hardware  or  some  form  of  standard  conformance  which  enables 

n°49  1°  "RT  JNRTCT"  ^  °r  **!?  isembedded  within  and  provides  a  consumer  go/nogo  test  (such  as 

“  ,  kun°IST  .)  Finally,  functional  test,  developed  by  the  customer  using  another  company's  die  and 

the  packaging  foundry's  substrate  and  assembly,  represents  this  customer's  interpretation  of  how  the 
components  will  interact,  and  may  be  based  upon  optimistic  simulation  models. 

3.1 .3.1  Test  Environment  Conclusion 

All  of  the  above  environment  factors,  coupled  with  the  wide  variety  of  MCM  applications,  from  low-cost 
consumer  applications  to  high-speed,  space-conscious  military  usage,  preclude  the  availability  of  a  single 
universally  applicable  MCM  test  methodology.  Instead,  the  proper  approach  for  a  given  package 
combination  must  be  selected  by  developing  a  set  of  priorities  and  implementing  a  strategy  which  targets 
specific  product  goals  at  each  level  of  packaging. 
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3.2  TEST  METHODOLOGY 

ldent5ied  itS  P?0rities  by  definhg  3  set  of  porous  targets  for  cost  and  tum-around- 
bme.  Such  aggressive  metrics  mandate  two  overall  test  strategy  themes.  First,  testing  must  be  non- 

atwLher r  l  at  Is’  tftS  S,h0Uld  be  applied  at  ^  631-11681  packaSe  level  possible,  and  should  not  be  repeated 
at  higher  jjaclcage  ievels  unless  it  can  be  done  so  at  minimal  cost.  Secondly,  complex  components  shoiSd  bf 

3.2.1  Assumptions 

3.2.1. 1  Good  Substrates  and  Good  Die 

Our  developed  methodology  assumes:  good  substrates  and  good  die.  Defect  free  die  and  substrate  must  be 

vwththeVel^tt'  TabIeS  m  **  manufacturi°g  Process  of  both  components  must  be  defined 

with  the  design  kit  groundrules.  Vanations  outside  the  process  tolerances  should  be  detected  by  in-process 
control  measurements,  and  not  by  subsequent  product  test.  P 

3.2.1. 2  Design  For  Test  (DFT) 

IEEE  1 149. 1  is  assumed  as  the  sole  DFT  approach.  While  it  is  not  necessaiy  that  all  components  be  1 149  1 

°TpIl3f’  strate§y=  which  partitions  the  design  into  1149.1  vs.  non-1 149.1  sections  and  develops  tests 
mdependently,  will  perform  more  effectively  on  the  1 149. 1  compliant  portions.  P 

3.2.13  Good  BSDL  and  Good  Netlist 

Any  methodology  will  rely  upon  the  availability  of  accurate  models.  The  1 149  1  emphasis  is  centered  unnn 

ET  Jo  to  toa*  of  1149  1  i^emetotio*  as  defied  via  to  Bounds  Sean 

h  h(i  1 1491B)[9].  The  BSDL  model  is  typically  provided  by  the  die  manufacturer,  and  should 

should  man  tf^h0r,t0'  T  s^nd  hardware  mod^l  is  the  netlist  of  the  substrate.  Thenetlist 
should  map  to  all  other  logic  and  schematic  models  on  a  one-to-one  basis. 

3.2.2  Basic  Approach:  Distributed  Testing 

The  assumptions  combine  to  permit  a  strategy  of  distributive  testing.  Die  and  substrates  will  be  assumed  to 
'3r°S  teSted  *7 ?eir  manufacturer>  precluding  the  need  for  retest  after  MCM  assembly  Thus  MCM 
su“fr  °n  ^  mdUC6d  dUnng  3SSembly’ 311(1  on  testinS  which  is  not  applicable  drning  die  or 

3.2.2.1  Die  Test:  Known  Good  Die  (KGD) 

^,™PT°hr^1Ce  °f  b6blg  ab!e  t0  as/ume  high-quahty  die  [10,12]  has  fostered  the  formation  of  an  industry 

Sppherl  Th^Krn  <f°^.referied  t0/8Known  Good  Die  (KGDX  is  to  develop  standards  for  die  ^ 
m^d?rm  S/S 1°  Pf  di6which  316  ****  38  rig^ously  as  packaged  single-chip 

chin  hum  •  a  rf’  !?  t0day  stechnol°gy>  implies  that  temporary  attach  or  other  methods  are  used  to  permit 
chpbum-m,  AC  tesfing  etc.  Such  screening  beyond  wafer  level  test  is  essential  to  provide  ad^Ste ET 
sembly  yields.  Furthermore,  the  KGD  activity  is  working  toward  ensuring  the  availability  of  physical 
dunension  data,  such  as  pad  placement,  which  is  essential  to  the  MCM  assJnbly  process  A  proposed 

S?ldfIt?I[  KnOWnGood  Die’ which  defi«es  the  design  data,  electrical  test  data,  quality 
assurance  and  reliability  provisions  was  distributed  at  the  1993  International  Test  Conference^!  1]  Finally 
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the  effort  represents  a  consolidated  force  encouraging  chip  manufacturers  to  provide  their  ICs  in  bare  die 
form,  a  service  which  some  suppliers  have  been  hesitant  to  provide. 

The  emphasis  on  meeting  the  quality  standards  defined  for  the  Single  Chip  Module  (SCM)  represents  a 
practical,  pragmatic  approach  to  KGD.  There  are  however  gaps  in  the  approach.  First,  one  can  argue  that  die 
to  be  mounted  on  an  MCM  need  to  be  tested  more  rigorously  than  its  SCM  counterpart,  given  the  expense  of 
rework  and  the  difficulty  of  diagnosing  faulty  components.  Furthermore,  there  is  no  guarantee  that  the 
existing  SCM  test  is  adequate  even  for  the  SCM.  For  instance,  what  sort  of  defect  coverage  do  the  tests 
meet?  What  types  of  defects  are  covered  (DC  stuck  fault,  delay,  bridging,  etc.)  [13,14]?  How  do  the  tests 
target  existing  production  facility  defect  distributions  [15]?  While  such  questions  are  critical  in  defining  die 
quality,  it  is  unlikely  that  they  will  be  directly  answered  by  the  die  supplier,  as  they  are  not  yet  provided  even 
to  the  packaged  die  customer. 

In  some  cases,  the  die  supplier  offers  the  option  of  purchasing  KGD  or  non-KGD  die,  where  the  difference 
tends  to  center  upon  whether  or  not  the  die  was  bumed-in.  Choosing  between  the  two  then  becomes  a  simple 
exercise  in  test  economics  [16,17],  where  the  decision  should  be  based  upon  the  quality  targets,  cost  of 
diagnosis/rework,  confidence  in  MCM  test  efficiency,  and  assumed  difference  in  Defects  Per  Million  (DPM) 
between  the  two  die  screening  approaches.  Clearly,  the  best  approach  from  an  MCM  foundry  perspective  is 
that  a  rigorous  test  be  applied  at  die  die  level,  where  such  rigor  is  defined  by  measurable  high  coverage  for  a 
variety  of  DC  and  AC  fault  models.  Targeting  specific  fault  classes  can  serve  to  ensure  that  the  applied  tests 
will  continue  to  provide  excellent  defect  coverage  over  the  evolution  of  the  typical  semiconductor  process 
facility. 

3.2.2.2  Substrate  Test:  Known  Good  Substrate  (KGS) 

The  test  objectives  for  unpopulated  substrates  are  well  defined  and  can  be  determined  from  the  physical 
layout.  A  high  quality  test  is  essential,  as  a  defective,  non-repairable  substrate  can  result  in  the  loss  of  all  the 
placed  die  if  detected  dining  MCM  assembly. 

3.2.2.3  MCM  Interconnect  Test 

The  objective  of  the  interconnect  test  is  to  verify  proper  connection  between  each  IC  and  to  the  module  I/O. 
Ideally,  this  is  established  by  developing  test  patterns  that  demonstrate  that  the  targeted  AC  and  DC  faults  do 
not  exist.  At  issue,  then,  is  to  establish  which  fault  classes  will  be  targeted,  and  on  what  nets.  The  primary 
fault  mechanisms  typically  assumed  for  interconnect  wiring  are  opens  and  shorts.  Open/shorts  tests,  which 
are  easily  applied  on  unpopulated  substrates  with  direct  access  to  each  net  node,  are  more  difficult  when  the 
net  is  subsequently  bounded  by  placed  chips  and  cannot  be  probed.  In  such  cases,  tests  must  be  applied  by 
deriving  a  set  of  test  patterns  that  logically  initialize  the  chip  driving  the  source  of  the  net  and  clocking  data 
across  the  net  into  some  other  chip,  whose  captured  state  is  then  read  out. 

Conformance  to  1 149. 1,  in  which  standardized  scanable  latches  are  placed  at  each  chip  I/O,  permits  this 
sequence  to  be  easily  implemented.  In  the  open/shorts  test  environment,  a  sequence  of  states  are  placed  upon 
all  interfacing  nets  which  can  test  for  any  net  to  net  short,  as  well  as  a  net  open.  Such  tests  can  be  developed 
independently  of  any  physical  placement/routing  information  and  require  only  a  net  list  showing  chip 
interconnections  and  BSDL  representations  for  each  die.  While  non-trivial,  this  test  generation  can  be 
considered  a  reformatting  of  standardized  tests  (walking  ones/zeros,  counting,  etc.),  and  is  independent  of  the 
logic  function  of  the  imbedded  ICs.  Interconnect  test  generation  algorithms  are  well  covered  in  [18,19].  The 
standardized  nature  of  these  tests,  and  the  ease  of  generation,  given  a  correct  substrate  net  list  and  die  BSDL, 
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make  this  an  ideal  test  to  be  generated  by  the  foundry  itself.  By  performing  this  step  on  its  own,  the  foundry 
can  control  output  format,  tests  applied,  and  can  capture  diagnostic  data  from  the  boundary  scan  tools. 

Foundry  test  generation  also  provides  more  flexibility  in  tester  hardware  configuration.  This  flow  is 
illustrated  in  Figure  3-2.  Totally  1 149. 1  compliant  MCM  designs,  have,  thus  far,  been  a  rare  commodity. 
Industry  surveys  have  found  that  only  40%  of  board  designs,  the  more  traditional  arena  for  boundary  scan, 
actually  use  boundary  scan.  In  the  case  of  mixed  1 149. 1/non- 1 149. 1  circuitry,  test  generation  becomes  more 
complex.  It  is  approached  by  creating  partitions  between  logic  that  are  totally  1149.1  and  the  non- 11 49.1 
circuitry.  The  non-1 149. 1  clusters  are  extracted  by  tracing  back  until  1 149. 1  latches  are  encountered,  and  by 
tracing  forward  to  1 149. 1  latches.  Such  clusters  can  contain  a  collection  of  non-1 149.1  ICs.  Tests  are  then 
generated  assuming  that  the  boundaries  of  the  cluster  are  primary  I/O.  The  boundary  scan  support  software 
then,  using  the  BSDL  and  netlist,  converts  these  patterns  into  a  series  of  scan  sequences  through  the  1 149. 1 
components,  and  also  generates  the  test  sequences  for  the  compliant  network. 
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At  issue  is  the  generation  of  tests  for  the  cluster  network.  The  details  of  the  internal  chips  may  not  be 
available,  thus  making  both  test  generation  and  simulation  (both  to  verify  fault  coverage  and  pattern  integrity) 
difficult.  Also  at  stake  is  the  fault  model  which  will  be  assumed  during  test  generation.  Today's  automatic 
test  pattern  generators  typically  use  the  single  stuck-at  fault  model.  While  this  model  covers  open  faults,  it  is 
inadequate  for  shorting,  or  bridging  faults.  On  the  other  hand,  generating  complete  open/shorts  test  as  in  the 

1 149. 1  case  can  be  impractical  due  to  the  large  number  of  states  that  would  have  to  be  propagated  forward 
and  backward  through  the  non- 1 149. 1  cluster  for  each  applied  pattern.  Such  a  task  is  not  only  CPU 
intensive  (and  thus  costly),  but  may  be  impossible  in  many  cases.  For  this  reason,  the  stuck  fault  model  is  the 
only  realistic  fault  model  given  today's  EDA  facilities. 


On  the  other  hand,  when  all  logic  components  are  1 149. 1,  and  the  only  other  die  on  the  MCM  are  non-1 149. 1 
memories,  a  complete  open/shorts  test  is  readily  accomplished.  This  is  due  to  the  standardized  operation  of 
most  of  today's  memory  die.  While  at  this  stage,  memory  test  pattern  generation  is  manually  performed, 

automatic  generation  should  not  be  far  in  the  future. 

Given  the  familiarity  of  the  foundry  with  the  objectives  for  open/shorts  testing,  and  with  a  variety  of  memory 
configurations,  die  generation  of  interconnect  tests  for  MCMs  with  the  logic/1 149. 1  and  memory/non- 

1149.1  die  sets  is  best  performed  by  the  foundry.  Where  more  than  just  memories  are  non-1 149.1,  the 
difficulty  of  test  generation  is  less  predictable.  In  such  cases,  the  clusters  should  be  extracted  and  single 
stuck-at  faults  assigned  to  the  interconnect  circuitry.  Automatic  test  generation  would  then  be  run  to  achieve 
whatever  level  of  coverage  the  customer  is  willing  to  support.  Manually  generated  patterns  may  also  be 
necessary  to  improve  the  coverage.  Test  generation  for  these  non-1 149. 1  clusters  should  be  performed  by  the 
customer,  not  the  foundry.  This  allows  the  customers  to  determine  how  much  money  and  time  they  are 
willmg  to  expend  to  achieve  the  test  quality  level  they  deem  necessary.  The  foundry  would  then  take  the 
responsibility  for  incorporating  these  cluster  tests  into  the  foundry  generated  1 149. 1  compliant  tests.  This 
flow  is  illustrated  in  Figures  3-3  and  3-4. 

In  the  illustrations,  the  test  generation  flow  has  started  with  partitioning  of  the  1 149. 1  circuitry  from  the  non- 

1 149. 1  components.  If  all  components  are  non- 1 149. 1,  the  entire  logic  representation  (assuming  it  is 
available)  is  presented  to  the  ATPG  software,  and  stuck  fault  tests  should  be  generated.  In  this  case,  all  tests 

are  generated  by  the  customer  and  shipped  to  the  foundry. 

3.2.2.4  Chip  Internal  Test 

The  ability  to  apply  tests  to  the  internal  logic  of  the  chips  mounted  into  an  MCM,  while  not  as  critical  as 
interconnect  testing,  can  still  significantly  improve  the  quality  of  the  MCMs  shipped.  It  is  thus  in  the  best 
interests  of  both  the  foundry  and  the  customer  to  perform  this  test.  While  still  permitting  broad  flexibility  in 

1 149' 1  does  provic!e  m  °Ptional  standard  instruction  sequence  to  enable  built-in  self 
test  (RUNBIST).  Hardware  on  the  chip  is  included  (such  as  pseudo-random  pattern  generators,  signature 
analyzers,  etc.),  and  the  steps  necessary  to  perform  this  test  are  documented  in  the  BSDL  [20]  This 
standardization  thus  allows  the  foundry  to  implement  BIST  for  each  1 149. 1  component  with  this  capability 
Seft  test  can  also  be  implemented  outside  the  realm  of  the  Test  Access  Port  (TAP)  controller,  either  on  a 

9. 1  or  non-1 149. 1  chip.  In  this  case,  it  would  be  up  to  the  customer  to  develop  the  patterns  and  provide 
them  to  the  foundry,  in  a  manner  similar  to  functional  test  patterns,  as  described  below. 
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JTAG/Non-JTAG 

Partitioning 


Figure  3-3:  Flow  for  Mixed  1149.1  and  Non-1 149.1  Die. 


3.2.2.5  Functional  Test 

Of  all  the  MCM  test  types,  the  functional  test  represents  the  greatest  risk  to  the  foundry.  Where  the 
difficulties  associated  with  functional  patterns  has  previously  been  described.  Key  to  developing  an  approach 
for  these  patterns  is  to  first  identify  which  are,  of  a  number  of  possibilities,  the  objectives  for  the  test.  If 
verifying  the  performance  of  the  MCM  is  the  prime  objective,  the  patterns  should  be  designed  to  exercise  the 
timing-critical  paths.  On  the  other  hand,  if  functional  verification  is  prime,  as  many  distinct  operations 
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should  be  exercised  as  possible.  Finally,  if  this  represents  the  sole  MCM  test,  attention  should  be  paid  to 
exercising  as  many  chip  interconnections  as  possible,  and  doing  so  in  a  sequence  that  enables  diagnosis. 


Regardless  of  the  objective,  however,  steps  must  be  taken  to  ensure  that  the  tester  is  capable  of  applying  the 
patterns.  These  considerations  must  be  accounted  for  prior  to  simulation  of  the  patterns.  While  post 
processing  tools,  such  as  software  from  Test  Systems  Strategies  Inc  (TSSI),  are  available  which  tend  to  take  a 
free-form  pattern  set  and  structure  it  into  the  cycle-based  form  necessary  for  tester  application,  such  efforts 
are  often  doomed  as  they  pre-suppose  the  acceptability  of  altering  the  timing  of  signals  without  changing  the 
response  timing.  Instead,  the  stimuli  must  be  converted  into  a  cycle-based  form  first,  and  then  the  simulation 
performed.  This  will  ensure  that  the  impact  of  any  timing  edge  movement  can  be  reflected  in  the  output 
response. 


3-13 


Even  with  this  pattern  structuring,  enough  variables  remain  for  functional  patterns  to  endanger  manufacturing 
cycle  time  commitments  from  the  foundry.  This  then  implies  that  either  hardware  delivery  dates  must  be  left 
open,  or  that  specific  tum-around  times  be  provided  for  foundry  supplied  tests  only.  A  preferred  alternative, 
that  meets  the  typical  customer's  interest  in  receiving  initial  hardware  as  soon  as  possible  for  engineering 
evaluation,  while  avoiding  placing  the  customer  in  the  production  volume  manufacturing  flow,  is  to  have  the 
customers  perform  MCM  functional  test  within  their  own  shop.  Given  today's  high  yielding  MCM  processes, 
it  is  reasonable  to  assume  that  a  high  percentage  of  initially  delivered  MCMs  are  defect-free  and  should  thus  * 
pass  correct  functional  patterns.  This  permits  complete  debug  of  the  functional  patterns  by  the  customer  who 
has  the  documentation  required  for  identifying  design  flaws  versus  manufacturing  defects.  Once  the  patterns 
are  verified  as  correct  by  the  customer,  they  can  then  be  transferred  to  the  foundry  and  applied  for  production 
hardware.  The  key  to  this  strategy  is  that  the  customer  and  the  foundry  have  comparable  tester  facilities.  This 
can  be  accomplished  either  by  the  foundry  usage  of  advanced  general  purpose  VLSI  ATE,  or  by  the  sharing 
of  test  fixturing  via  the 'golden  module' approach. 

3.2.3  Implementation  Aspects  of  Test 

There  are  two  key  elements  to  the  implementation  of  this  methodology:  EDA  software  support  and  selection 
of  test  equipment. 

3.2.3. 1  EDA  Software  Support  Elements 

Ideally,  test  generation  software  should  provide  the  following  attributes: 

1.  Die-level  automated  1 149. 1  compliance  verification.  This  includes  checking  the  logic  to  ensure  that  the  die 
hardware  correctly  implements  1 149. 1,  and  also  the  automatic  extraction  of  a  BSDL  representation. 

2.  A  smgle  consolidated  logic  model,  reflecting  the  test  strategy  that  will  be  applied  for  each  MCM 
component.  Specifically,  if  the  component  is  1 149. 1  compliant,  the  representation  should  be  BSDL-based. 

For  non-compliant  designs,  a  primitive  logic  level  description  would  be  necessary.  RAMs  and  ROMs  should 
be  considered  as  primitives. 

3.  The  ability  to  automatically  partition  the  1149.1  andnon-1149.1  representations  so  that  the  non- 1149.1 
clusters  can  be  extracted. 

4.  An  extraction/test  generation  approach  that  maximizes  complete  open/short  testing,  while  reverting  to 
stuck-at  fault  detection  when  necessary.  This  includes  consolidating  both  fault  coverage  metrics,  so  that 
excess  patterns  are  not  generated. 

5.  Support  for  scan  DFT  approaches,  such  as  Level  Sensitive  Scan  Design  (LSSD),  for  those  components  that 
are  non- 1149.1.  Ideally,  scan  and  1149.1  could  be  completely  mixable,  so  that  scan-based  designs  would 
receive  the  same  level  of  test  coverage  as  1 149. 1  components. 

6.  Usage  of  industry  standard  pattern  formats,  such  as  WAVES  (IEEE  Standard  1029. 1),  to  remove 
dependencies  on  specific  EDA  packages. 

3.2.3.2  Test  Equipment  Implications 

Given  the  aggressive  cost  targets  defined  for  the  ASEM  program,  extreme  care  must  be  taken  in  selecting  the 
test  equipment  used  during  MCM  testing.  The  tester  selected  will  depend  primarily  on  the  tests  to  be  applied 
In  1 149. 1-based  design  environments,  low-speed,  low-pin  count  testers  can  be  used,  minimizing 
manufacturing  costs.  In  this  environment,  1 149. 1  devices  are  added  to  the  test  fixture  to  provide  stimuli  to 
the  MCM  primary  I/O.  This  approach  precludes  the  application  of  parametric  tests,  such  as  input  and  tri-state 
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leakage,  tests  which  may  be  either  completely  skipped,  or  applied  on  other  testers.  Also  precluded  is  the 
application  of  broad-side  functional  patterns  at  AC  speeds. 

The  next  better  test  system,  given  the  low  pin  count  requirements  of  this  approach,  is  the  usage  of  a  high- 
performance,  but  low  pin  count  tester.  In  this  approach,  high  speed  pin  electronics  is  used  to  provide  a 
functional  at-speed  Built-in  Self  Test  (ACBIST),  assuming  the  components  have  this  capability 
in  hardware.  As  tester  cost  very  much  depends  on  the  number  of  pins,  this  permits  the  usage  of  high-tech 
equipment  at  a  reasonable  cost.  In  those  cases  where  high  speed  functional  patterns  will  be  applied,  and/or 
manufacturing  cycle  time  is  to  be  minimized,  the  usage  of  high-speed  general  purpose  test  equipment  can 
more  easily  be  justified.  This  is  especially  true  for  the  case  in  low-volume  applications,  where  the  actual 
tester  usage  is  minimal.  Given  the  broad  range  of  ideal  test  environments,  the  ideal  foundry  would  have 
access  to  a  wide  variety  of  testers,  and  thus  be  able  to  optimize  for  a  specific  application. 

3.2.3.4  Format  Standards 

While  standards  have  been  defined  for  the  three  major  sources  of  input  for  testing,  each  has  its  own  special 
considerations.  EDIF  2.0.0  is  widely  supported  for  defining  netlists  and  schematics.  However,  the  broad 
flexibility  defined  within  the  standard  is  rarely  completely  implemented  within  a  given  EDA  system. 
Additionally,  its  loose  structure  allows  different  usage  of  EDIF  elements.  The  resulting,  less  than  rigorous, 
interpretations  complicate  general  purpose  EDIF  capture  software.  On  the  other  hand,  BSDL,  as  defined  by 
the  proposed  standard  1 149.  IB,  is  well  documented. 

The  difficulty  here,  independent  of  the  standard  itself,  is  getting  reliable  BSDL  for  die.  As  the  BSDL  is  not  a 
necessary  input  to  die  manufacturing  test,  the  die  manufacturer  has  no  strong  incentive  to  ensure  accuracy. 
Released  BSDL  should  be  verified  by  generating  1 149. 1-based  tests  on  each  chip  in  a  single-chip  (SCM) 
configuration  and  then  either  simulating  these  tests  using  the  full  logic  representation  by  applying  the  patterns 
at  the  tester.  The  broad  support  for  EDIF  and  BSDL  does  not  hold  true  for  WAVES.  While  most  of  the 
major  EDA  suppliers  intend  to  ultimately  support  the  import  and  export  of  patterns  in  this  format,  the 
capability  does  not  exist  today.  Criticism  is  wide-spread,  and  often  focuses  on  the  difficulty  in  expressing 
tanmg  data.  In  the  absence  of  an  industry  standard,  conversion  packages,  such  as  TSSI  have  become  a  de 
facto  standard,  by  providing  the  ability  to  go  from  a  variety  of  EDA  systems  to  a  variety  of  testers.  This 
availability  of  a  viable  alternative  in  turn  lessens  the  incentive  for  EDA  suppliers  to  invest  in  WAVES 
support,  further  entrenching  the  alternatives. 

3.2.3.S  Data  Integrity 

A  key  element  in  successful  transfer  and  use  of  data  in  a  multisupplier  and  multiuser  environment  is  that 
various  elements  of  the  data  resources  should  map  on  a  one-to-one  basis  and  the  use  of  clear  and 
unambiguous  naming  conventions..  In  a  vertically  integrated  design  environment,  these  issues  are  often 
automatically  handled  since  only  one  source  of  design  information  exists.  However,  in  a  distributed  design 
and  test  environment  several  sources  of  information  may  exist  which  do  not  use  the  same  format  or  naming 
conventions.  It  is  important  at  the  beginning  of  the  system  design  phase  to  put  in  place  a  process  to  ensure 
that  cohesiveness  and  correctness  in  the  design  database  is  maintained. 

3.2,4  Diagnostic  Implications 

An  essential  element  of  providing  a  low-cost  MCM  assembly  capability  is  the  ability  to  easily  identify  which 
component  is  defective  and  rework  it.  1 149. 1-based  designs  provide  superior  fault  isolation  for  the 
interconnect  circuitiy  and  die  internal  logic  if  BIST  is  implemented.  In  most  cases,  a  repair  decision  is  based 


3-15 


upon  the  cost  associated  with  the  repair  process  versus  the  cost  of  the  raw  materials  such  as  dies  and 
unpopulated  substrates.  For  instance,  flip-chip  mounted  MCMs  are  significantly  more  economic  to  repair 
than  wirebonded  or  TAB  interconnect  assembly  techniques.  An  economically  viable  rework  process 
improves  effective  manufacturing  yields,  and  reduces  product  cost.  In  those  cases  where  the  diagnostic 
procedure  is  more  intensive,  such  as  in  the  non- 1 149. 1  designs,  or  for  functional  test  patterns,  it  becomes 
more  likely  that  repair  will  be  abandoned,  depending  on  the  percentage  of  MCMs  failing  this  test  type  and  the 
value  of  the  MCM  components. 

For  prototype  MCM  development  module  I/O  pins  specifically  added  for  test  purposes  may  greatly  enhance 
the  test  coverage  and  diagnostic  capability  through  improved  observation  and  control  during  interconnect  or 
functional  test.  In  many  cases  additional  pins  may  be  added  with  negligible  additional  costs.  The  added  pins 
are  particularly  useful  for  MCMs  using  flip  chip  bonding  because  of  the  reduced  visual  inspection  capability 
as  compared  with  wirebond  methods.  However  the  addition  of  net  branches  and  extra  signal  line  length  will 
alter  the  electrical  characteristics  of  the  net.  Changes  in  reflection  characteristics,  crosstalk,  and  di/dt 

coupling  noise  must  be  incorporated  into  the  system  level  simulation  to  ensure  proper  functioning  of  the 
design. 

Examples  of  Design-For-Test  practices: 

1 .  Add  an  observation  pin  between  each  device  in  the  1 1 49. 1  scan  chain. 

2.  Scan  chain  order  is  important.  Select  the  die  with  the  most  module  I/O  observability  for  the  module  TDI. 

3.  Add  module  I/O  for  key  control  signals.  Such  as  Output  Enable  for  an  SRAM  memoiy  bank. 

4.  Use  as  many  module  I/O  as  are  available  to  improve  observability. 

5.  Staged  assembly  during  prototyping  to  minimize  fault  possibilities  during  initial  bring  up. 

3.2.5  Methodology  Conclusion 

To  meet  the  aggressive  ARPA  goals  of  reduced  NRE  cost  and  turn  around  time  for  low  volume  MCM 
development,  a  module  test  methodology  requires  some  basic  assumptions  be  made,  such  as  KGD,  KGS, 
good  BSDL,  good  netlists  and  must  provide  an  appropriate  minimum  set  of  tests.  In  an  environment  where 
Known  Good  Die  and  Known  Good  Substrates  are  available,  we  believe  OEM  customers  are  best  served  by 
providing  a  test  set  which  concentrates  on  verifying  bond  and  MCM  trace  continuity.  Additional  tests  are 
provided  only  where  the  test  environment  is  compatible  and  the  design  and  schedule  permit.  IEEE  Standard 
1 149. 1  provides  a  highly  efficient  framework  for  implementing  this  test  approach. 
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3.3  INTERCONNECT  TEST  IMPLEMENTATION 


Introduction 


The  MCM  test  offering  which  meets  the  ARP  A  NRE  cost  and  turn  around  time  goals  exploits  the  emerging 
use  of  the  IEEE  1 149. 1  standard.  The  1 149. 1  methodology  provides  an  efficient  and  transportable  method 
for  accomplishing  MCM  assembly  verification  by  providing  electronic  testing  of  interconnects  and  bonds. 
Given  an  assembly  comprised  of  known  good  components,  the  most  likely  source  of  failures  will  be 
manufacturing  defects  related  to  the  assembly  process.  This  is  an  observation  which  IBM  MCM  test  shares 
with  board  manufacturers  and  provides  justification  for  the  effort  spent  on  fault  isolation  associated  with 
assembly  verification  test  (often  referred  to  as  Interconnect  Test).  The  assembly  verification  test  is  analogous 
to  that  used  by  circuit  board  manufacturers  after  board  assembly  and  before  system  functional  test  and 
includes  reliance  on  the  use  of  Known  Good  Die  (KGD)  in  the  MCM  or  in  a  card  assembly  to  ensure  high 
first  pass  yields.  High  first  pass  yields  also  require  the  MCM  substrate  to  be  a  "Known  Good  Substrate" 
(KGS)  and  that  the  design  and  simulation  tools  be  properly  adapted  to  the  material  system  characteristics. 
Physically,  interconnect  testing  is  performed  using  a  1 149. 1  based  flexible  fixturing  scheme  which  enables 
reduced  turn  around  time  and  reduced  costs  through  ATPG  and  reuse  of  fixture  components.  An  added 
benefit  of  the  1 149. 1  testability  standard  is  that  it  provides  the  means  to  initiate  an  electronic  structural  test  of 
die  through  the  use  of  1 149. 1  accessed  Built  In  Self  Test  (BIST). 

Interconnect  Test  Overview 

The  test  process  begms  with  early  involvement  with  the  customer  concerning  the  manufacturabilty  and 
testability  of  the  design.  A  preliminary  evaluation  of  the  first  pass  yield  of  the  module  is  estimated  based  on 
customer  supplied  MCM  design  and  die  yield  data.  The  data  considered  should  include  test/yield  information 
for  each  Design  For  Test  (DFT)  feature,  at  both  the  die  and  module  level,  the  module  signal  architecture,  and 
signal/power  specifications.  Designs  which  include  some  1 149. 1  die  or  are  100%  populated  with  1 149. 1  die 
generally  fit  the  criteria  for  low  cost  assembly  verification.  Given  a  design  which  fits  the  low  cost 
interconnect  test  process,  detailed  information  requirements  are  requested  from  the  customer.  The 
information  requested  comprises  a  subset  of  the  total  module  or  system  design  information  and  includes 
device  interface  descriptions.  Boundary  Scan  Description  Language  (BSDL)  for  1 149.1  compliant  die, 
module  I/O  data  and  process  information. 

Test  patterns  for  the  module  are  obtained  using  Automatic  Test  Pattern  Generation  (ATPG)  and  include  all 
nets  terminated  in  at  least  two  1 149.1  boundary  cells.  ATPG  is  accomplished  using  Teradynes'  Victory™ 
software  package  and  the  test  patterns  are  output  as  a  Serial  Vector  Format  (SVF)  test  file.  Fault  types 
addressed  by  ATPG  are  single  stuck-at  fault  models  such  as  stuck  driver  or  shorted/open  nets.  ATPG 
coverage  includes  MCM  I/O  since  we  include  a  1 149. 1  based  test  fixture  in  the  ATPG  database.  Coverage 
is  extended  to  nets  terminated  by  non-1 149.1  devices  using  manually  generated  patterns  which  are  applied  to 
the  device(s)  or  interconnects  under  test  using  1 149. 1  test  resources.  A  Victory  software  tool,  VCCT,  is 
used  to  serialize  manually  generated  test  patterns  and  output  an  SVF  test  data  file  for  use  by  the  test 
equipment.  Interconnect  test  coverage,  assuming  a  single  stuck  at  fault  model,  can  approach  100%  for 
designs  with  sufficient  boundary  scan  die  and/or  appropriately  designed  test  vectors. 

The  MCM  is  bond  and  interconnect  tested  a  number  of  times  during  the  prototype  bond  and  assembly  process 
in  order  to  assure  that  assembly,  capping  and  handling  do  not  introduce  defects  into  the  product  and  are  not 
passed  on  as  a  defective  assembly  to  the  customer.  The  most  critical  juncture  in  minimizing  test  turn  around 
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time  is  the  first  pass  at  newly  assembled  MCM  part  numbers.  A  problem  with  either  the  test  information 
database  or  test  generation  process  can  introduce  unacceptable  delays  into  the  MCM  build  schedule.  These 
P°  n  1  ,f,ayS  Je  mminuzed  by  generating  and  applying  tests  to  a  prototype  printed  circuit  board  (PCB) 
version  of  the  to-be-built  MCM  during  the  MCM  build  cycle.  Prototype  PCB  (or  brassboard)  testing  can 
identify  design  eirors  as  well  as  database  eirors  such  as  incorrect  BSDL  description.  The  use  of  Brassboard 
esign  verification  by  the  system  designer  is  strongly  recommended  before  undertaking  MCM  prototyping 

Known  Good  Die  Overview 

Known  Good  Die  (KGD)  play  an  important  role  in  providing  a  known  die  quality  value  for  reducing  the 
compleaty  and  cost  of  module  level  testing  and  diagnostics.  The  widely  accepted  definition  of  KGD  states 
that  the  die  should  be  of  similar  quality  to  that  of  a  single  chip  packaged  part.  This  means  the  die  should 
perfonn  at-speed  and  within  the  published  specifications.  Many  die  suppliers  are  currently  gearing  up  to 
provide  KGD  through  the  use  of  Temporary  Chip  Attach  (TCA)  methods  or  through  the  use  of  more 
sophisticated  wafer  level  testing.  At  the  present  time  however,  few  die  suppliers  offer  a  competitively  priced 
selection  of  KGD.  Instead,  what  suppliers  offer  is  a  not  at-speed  functional  wafer  level  test,  combined  with  a 
Lot  Acceptance  Test  (LAT.)  The  LAT  is  performed  by  packaging  samples  of  die  from  each  wafer  and 
running  these  parts  through  the  normal  packaged  part  test  program.  The  fallout  information  from  this  test  is 
used  to  predict  the  actual  fail  rate  expected  from  the  bare  die  when  they  are  run  at-speed. 

At  IBM  we  currently  support  TCA  packaging  for  C4  die.  The  TCA  substrate  uses  a  metalized  ceramic  or 
multi  layer  ceramic  earner  in  combination  with  palladium  dendrite  land  pads  for  the  die  I/O  bumps.  Die  are 
compressively  held  in  place  by  a  sprung  plate  assembly  which  is  an  integral  part  of  the  heat  sink  assembly. 

e  TCA  module  is  designed  to  be  similar  to  the  footprint  and  electrical  characteristics  of  packaged  parts 
using  the  same  (he.  The  package  similarity  allows  the  TCA  module  to  be  inserted  into  the  die  suppliers  test 
process  flow  with  ammimum  of  process  development  or  cost.  Alternatively  if  test  vectors  are  available  (not 
often  the  case)  die  TCA  module  can  be  tested  on  in-house  Automatic  Test  Equipment  (ATE )  A  third 
process,  which  inserts  the  TCA  module  temporarily  into  the  prototype  printed  circuit  board  for  a  system  level 
functional  test,  is  also  possible  but  carries  a  higher  risk  from  the  diagnostic  point-of-view  and  is  not  well 
suited  for  volume  production.  The  advantages  provided  by  the  prototype  PCB  system  functional  test  are  that 
rt  provides  an  alternative  if  a  complete  ATE  test  is  not  possible.  However,  this  approach  carries  a  higher  risk 

fbr'fault  isdadon 10  p0mt*°f‘View  because  system  test  Pattems, which  ^  typically  used,  are  not  designed 

The  following  sections  of  the  report  will  expand  on  the  various  elements  of  the  test  methodology  which  we 
have  unplemented^  A  discussion  of  the  requirements  for  our  ATPG  software  platform  and  the  selection 
criteria  for  the  ATPG  software  will  be  followed  by  a  brief  description  of  the  MCM  fixturing  scheme  we  have 
implemented  to  reduce  the  cost  and  improve  the  Tum-Around-Time  (TAT)  of  our  assembly  verification 

th?eienl.ftS  °fthe  t6St  database  which  we  *****  ^  how  we  generate  test  vectors 
for  the  MCM  will  be  described.  Next,  the  test  process  itself  is  described  and  includes  the  rationale  for  using 

the  customers  prototype  PCB  as  part  of  the  test  debug  process.  The  section  will  conclude  with  a  description 
of  our  benchmark  process  and  present  benchmark  test  cost  and  TAT  data. 

3.3.1  Software  Platform 

The  software  requirements  for  implementation  of  a  1 149. 1  assembly  verification  test  are  that;  the  software 
should  be  able  to  check  syntax,  read  and  parse  Boundary  Scan  Description  Language  (BSDL)  files,  integrate 
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these  files  with  an  MCM  netlist,  provide  ATPG  and  produce  a  machine  independent  test  vector  file. 
Additionally,  the  software  should  support  application  of  alternate  source  test  vectors  by  providing 
appropriate  serialization  and  test  vector  files  for  use  by  1 149. 1  MCM  and  tester  resources.  Another 
requirement  concerns  support  of  the  software  over  time  by  the  software  manufacturer.  The  desired  software 
support  would  provide  long  term  software  maintenance  with  an  apparent  resource  base  (i.e.:  well  established 
support)  to  support  revision  engineering  and  distribution.  Finally,  the  software  manufacturer  should  have  in 
p  ace  a  plan  detailing  future  enhancements  to  the  software  and  a  plan  for  future  growth  of  their  product  in  the 
test  marketplace. 


While  there  are  several  suppliers  of  1 149. 1  test  generation  tools,  only  one  was  found  to  meet  our  selection 
and  requirement  criteria.  The  tool  we  selected  is  marketed  by  Teradyne  and  is  called  "Victory."  This  tool 
provides  all  of  the  previously  mentioned  features.  It  also  provides  several  additional  support  features  such  as 
EDIF  NETLIST  input.  Figure  3-5  illustrates  the  basic  environment  and  functions  of  the  Victory  tool. 
Teradyne  has  both  experience  in  the  test  arena  and  has  a  significant  infrastructure  which  helps  to  support  the 
ongoing  development  and  deployment  of  the  Victoiy  product  across  Teradyne  and  other  test  equipment 
hardware  platforms.  Notably  Texas  Instruments  uses  the  Victory  ATPG  function  in  it's  "ASSET"™ 
benchtop  test  system.  Additionally,  Teradyne  has  worked  with  several  electronic  test  development  vendors  to 
develop  a  tester  independent  output  file  specification.  The  test  data  file  specification  is  called  Serial  Vector 
Format  (SVF)  and  provides  a  straightforward  means  of  transferring  Victory  generated  test  data  output  to 
non-Teradyne  test  equipment. 


BSDL 


EDIF 

NETLIST 


MANUAL 

PATTERN 

GENERATION 


SRAM  l/F 


l/F  =  Interface  Specification 


VICTORY 


BSDL  checking 
NETLIST  extraction 
BSDL /NETLIST  XREF 
Test  Generation 

*  BSDL  Interconnect  Test 

*  BIST  Test 

*  Test  Access  Port  (TAP)  Test 

*  Parallel  to  Serial  Conversion 

Standard  Test  File  Output 

*  Serial  Vector  Format  (SVF) 

Test  Coverage  Analysis 


Figure  3-5:  Automatic  Test  Pattern  Generation  (ATPG)  for  Interconnect  Test 
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3.3.2  Flexible  Fixturing  Hardware 

In  order  to  reduce  the  NRE  cost  and  TAT  associated  with  providing  fixturing  and  thermal  management  for 
uncapped  MCMs  a  semi-standardized  fixturing  scheme  has  been  implemented.  Referring  to  Figure  3-6,  the 
main  components  of  the  setup  are  a  bank  of  IEEE  1 149. 1  based  devices  which  provide  drive  and  observe  to 
the  MCM  I/O,  a  signal  and  power  redistribution  daughter  card,  a  pneumatic  Zero  Insertion  Force  (ZIF)  socket 
and  dry  nitrogen  impingement  cooling.  SVF  test  data  is  translated  on  a  PC  and  is  supplied  to  the  1 149. 1  test 
electronics  through  our  interconnect  test  system. 

Savings  in  fixture  cost  and  TAT  are  realized  because  only  a  relatively  simple  printed  circuit  daughter  card 
needs  to  be  fabricated  for  each  new  MCM  part  number.  The  card  redistributes  wiring  from  the  tester  and 
power  supplies  to  the  appropriate  ZIF  connector  pin.  Switching  between  different  product  fixtures  requires 
that  only  the  daughter  card  be  swapped,  cables  reconnected  and  the  back  side  of  the  double  sided  ZIF  socket 
engaged.  The  information  required  for  fixturing  a  specific  MCM  comes  from  the  test  database  and  includes 
netlist,  module  level  connector,  physical/electrical  schematics  and  thermal  information. 


*  Expands  i/o  >760 

*  Flexible  Configuration 


Figure  3-6:  MCM  Interconnect  Test  System 


Thermal  management  for  uncapped  MCMs  is  provided  by  dry  nitrogen  impingement  cooling  The  test 
fixture  has  a  doorlike  cover  which  contains  a  standard  sized  gas  distribution  gallery.  The  gallery  cover  plate 
closest  to  the  MCM  under  test  consists  of  a  plate  with  tubular  orifices  which,  when  the  door  is  closed,  directs 
the  nitrogen  flow  directly  onto  the  chips  requiring  cooling.  The  readily  replaceable  cover  plate  is  simple  in 
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design,  and  inexpensive  to  fabricate,  thus  reducing  the  cost  and  TAT  associated  with  thermal  management 
during  uncapped  testing  of  MCMs. 

3.3.3  Database 

The  information  required  for  testing  MCMs  covers  most  aspects  of  the  design.  Test  database  information 
needed  for  a  module  comes  from  several  sources.  Typically  the  OEM  customer  will  provide  design 
specification  and  die  descriptions  and  the  substrate  foundry  will  provide  physical  dimension  information  for 
the  substrate,  MCM  I/O,  cap  and  heatsink.  Figure  3-7  lists  the  major  elements  of  the  test  information 
database  required  to  perform  interconnect  assembly  verification  test.  An  example  of  a  more  detailed 


TEST  INFORMATION  DATABASE 

♦  ASIC  BSDL 

♦  NON-1149.1  DIE  INTERFACE /CHARACTERISTIC  FILES 

♦  NETUST 

♦  MCM  I/O  SPECIFICATION 

♦  PIN  CROSS  REFERENCE 

♦  PHYSICAL  and  ELECTRICAL  SCHEMATICS 

♦  THERMAL  DATA 


Figure  3-7:  Test  Information  Database 


worksheet  is  provided  in  Figure  3-17  in  Section  3.5,  Data  Integrity.  Functional  test  on  ATE  or  system  level 
test  is  handled  on  a  case-by-case  basis.  Figure  3-8  illustrates  the  general  flow  of  test  data  and  where  in  the 
process  data  conversion  and  vector  generation  occurs  for  interconnect  and  functional  test. 
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Figure  3-8:  Test  Generation  Process 


3.3.4  Test  Vector  Generation 


Th^p“ts  to  the  ATPG  Portion  of  the  test  vector  generation  software  consist  of  device  BSDL,  netlist  scan 
path  definitions,  non-1 149. 1  device  characteristic  models  and  nomenclature  translation  tables.  Given  correct 
database  information  the  ATPG  portion  of  the  test  can  be  generated  in  a  very  short  time  (<lhr.)  If 
construction  of  characteristic  model  files  is  performed  manually,  the  task  can  often  be  performed  using 
device  specification  data  sheets  within  one  day.  However,  if  the  information  database  contains  conflicting 

°r  thC  BSDL  6IeS  have  unresolved  conflicts  in  their  internal  descriptions  and/or  missing 
BARE_DIE  pin  name  descriptions,  the  resolution  of  naming  issues  can  be  time  consuming. 


TheVictory  ATPG  software  provides  three  distinct  sets  of  vectors.  Each  vector  consists  of  drive  data  driver 
enable  data,  expect  data  and  mask  (care/don't  care)  data.  The  expect  data  is  an  appropriate  response  vector 
or  each  vector  generated,  which  is  used  with  the  mask  data  to  allow  comparison  with  the  observed  response, 
he  first  set  of  two  vectors  is  a  stuck  driver  pattern  where  all  drivers  are  set  to  the  same  value  followed  on  the 
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next  cycle  by  their  complement.  The  second  set  of  vectors  enables  drivers  on  the  opposite  ends  of  the  nets 
from  the  stuck  driver  vector  set  and  is  also  set  up  as  a  stuck  driver  test.  The  number  of  vectors  in  this  set  is 
governed  by  the  net  with  the  greatest  total  number  of  individually  controllable  drivers  (D)  and  is  equal  to 
2*D-2  (*  =  multiplication).  The  third  set  of  vectors  is  a  counting  pattern  and  its  complement.  The  counting 
pattern  vector,  which  is  a  minimum  number  vector  set,  guarantees  that  eveiy  net  will  be  at  an  opposite  state 
to  every  other  net  at  some  time  within  the  vector  set.  This  guarantee  provides  the  ability  to  detect  and 
diagnose  any  single  net-to-net  short  or  detect  any  multiple  net  shorts.  The  number  of  vectors  in  the  set  is 
governed  by  the  number  of  testable  nets  (N)  and  is  equal  to  2*log(N+2).  Further  information  about  the  test 
vector  sets  and  the  significance  and  format  of  the  various  tools  can  be  found  in  literature  and  training  manuals 
available  from  Teradyne. 

Manual  test  pattern  generation  is  performed  using  product  data  sheets,  module  netlist  and  1 149. 1  device 
models.  The  patterns  are  crafted  using  appropriate  vector  types,  as  described  in  Section  6.3.2.7  AD VI  Test, 
and  appropriate  timing  and  control  signal  levels  as  described  in  the  device  data  sheets.  The  patterns  applied 
are  specifically  developed  to  stimulate  an  interconnect  fault  type  and  capture  a  result  which  allows  as  specific 
a  diagnosis  as  possible.  Often,  as  in  the  case  of  memory  devices,  the  control  signals  are  not  directly 
observable  so  opens  or  shorts  faults  on  these  lines  must  be  inferred  from  the  read  write  behavior  of  the 
device.  The  test  patterns  are  written  in  a  Victory  specific  parallel  vector  format.  The  format  relates  the 
parallel  vector  format  file  to  the  netlist  and  topology  files  and  generates  intermediate  mapping  files  which 
map  the  non- 11 49.1  testnodesto  1149.1  drive/receive  resources.  The  final  step,  also  performed  by  Victory, 
serializes  the  data  into  a  machine  independent  SVF  test  vector  file.  The  serialization  process  may  also  be 
used  on  any  cycle  based  parallel  vector  set  which  meets  the  drive/receive  capability  available  through  1 149. 1 
based  and/or  other  controllable  testa*  resources. 

3.3.5  Test  Database  Verification 

Database  verification  plays  an  important  role  in  meeting  our  short  turn  around  time  commitments  in  the  OEM 
market.  Figure  3-9  illustrates  the  process  flow  incorporating  the  prototype  PCB  test  verification  procedure. 
As  the  figure  illustrates,  MCM  hardware  is  not  available  until  near  the  end  of  the  build  and  delivery  schedule. 
Debugging  incorrect  test  data  and/or  hardware  can  take  considerable  time  and  effort  and  usually  cannot  be 
reliably  accomplished  in  a  1-2  week  time  frame.  The  use  of  the  prototype  board,  even  if  it  is  not  exactly  the 
same  as  the  MCM  design,  allows  debugging  and  verification  of  BSDL,  netlist  and  nomenclature  issues, 
characteristic  device  models,  test  patterns,  power  and  initialization  turn-on  and  turn-off  procedures.  If  all 
database  information  is  correct,  database  verification  can  be  accomplished  in  short  order  (<2-3  days.) 
Manually  generated  test  patterns  can  also  be  verified  if  the  prototype  board  uses  the  same  netlist  as  the 
^CM.  Otherwise,  the  data  used  for  manual  pattern  generation  can  still  be  verified  for  syntax  and 
nomenclature.  The  time  required  for  this  activity  is  dependent  on  the  complexity  of  the  test  patterns  which 
jpist  be  developed.  Non-1 149. 1  based  machine  generated  test  patterns  supplied  by  the  customer  can  also  be 
verified  using  this  procedure.  However,  failures  which  may  occur  are  often  difficult  to  diagnose. 
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MCM  Available 
for  Test 


Figure  3-9:  Interconnect  Test  Assembly  Verification,  1149.1  Based 


An  additional  use  for  the  prototype  PCB  is  as  a  functional  screen  for  TCA  modules  destined  for  use  in  the 
MCM.  If  a  true  KGD  is  not  available,  the  use  of  the  prototype  PCB,  modified  with  ZIF  sockets  to  accept  the 
TCA  module,  may  be  justified  depending  on  prototype  MCM  yield  management  data.  As  with  test  vectors 
generated  by  a  remote  design  system,  functional  screening  code  should  be  tightly  organized  and  documented 

in  order  to  maximize  the  diagnostic  utility  of  the  screening  procedure. 

We  also  find  that  BSDL  data  can  be  verified  by  testing  a  single  chip  module.  The  single  chip  module  is 
socketed  (at  different  times),  in  two  separate  ZIF  sockets.  The  first  socket  is  used  to  check  the  scan  chain 
length,  Test  Access  Port  (TAP)  and  all  bidirectional  driver  receiver  pairs.  Since  the  input  side  of  a 
bidirectional  port  is  wired  internally  to  its  associated  output,  the  drive  and  receive  capability  of  the  ports  may 
be  readily  determined.  The  second  socket  provides  pin-to-pin  connections  between  appropriate  signals  on  the 
device  under  test  by  'wrapping'  drivers  to  receivers.  Using  the  pin-to-pin  netlist  for  the  second  socket  (the 
wrap  fixture),  die  ATPG  tool  is  used  to  generate  a  test  of  all  interconnected  leads.  This  test  provides 
verification  of  driver/input  BSDL  descriptions  for  all  types  of  ports  when  combined  with  the  results  of  the 
test  using  the  first  socket. 

3.3.6  Interconnect  Test 

Once  assembled  MCM  hardware  is  received,  the  MCM  specific  load  board  fixture  is  mounted  to  the  thermal 
management  fixture  and  tester.  The  first  step  in  the  test  process  is  a  parametric  characterization  of  power  and 
ground  planes  for  proper  resistance  values.  ESD  diode  characterization  may  also  be  performed  to  check  for 
MCM  lead-to-die  signal  I/O  continuity.  Once  the  MCM  is  socketed  and  cooling  gas  flow  is  established. 
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*°nS  ^  **  neCCSSary  Signal  Preconditioning  *en  a  check  for  in-limit  current 


The  next  step  involves  application  of  a  Test  Access  Port  Integrity  Test  (TAPIT).  The  TAPIT  verifies  scan 

TDO,  test  clock  and  TMS  distribution,  die  ID  code  (if  implemented)  bypass 

ktermnn^ft^  ^  ^ 1  device(s)  hstTuctloa  ^ters.  The  TAPIT  test  is  followed  by  &e 

interconnect  test  proper  and  application  of  any  non- 1 149. 1  test  patterns.  Comparison  failures  in  any  of  these 

snSS116^  t*?  ^  f?WC  file  Which  is  mQd  for  diagQostics-  Diagnostic  analysis  returns  a  repair  order 
specifying  which  die  must  be  reworked.  After  die  rework  the  MCM  is  retested. 

3.3.7  Test  Implementation  Conclusion 

^:rreT0.n  0f  teSt  has  been  successfully  accomplished  and  is  demonstrated  in  the 

•  f  <?Jd  S,m  SeC  ®"  3f  ,The  1 14r9' 1  based  test  methodology  has  a  key  dependency  which  is  a  reliance  on 
dustiy  wide  support  and  adoption  of  the  1 149. 1  standard.  Once  the  1 149. 1  standard  becomes  more  widely 

ch  i/k  S6T 1 4  b,f  haPPemnS’  costs  associated  with  debugging  incorrect  or  incomplete  BSDL  descriptions 
S  belo!fUCed  ^  r6dUCmg  NRE  C°StS'  SummaT}r  of  ^  key  features  and  how  they  are  implemented  are 


Features 

*  Automatic  Test  File  Generation 

•  Ease  of  fixturing  constraint 

•  Eliminate  Data  Integrity  concerns 

*  Known  Good  Die 

Improved  diagnostics  and  test  coverage 


Implementation 

Teradyne’s  Victory  Platform 

Flexible  and  standardized  electrical  and  thermal  fixtures 

Rigorous  and  standardized  test  plan,  customer  interface 
and  data  verification  using  brassboard  prototype  and 
single  chip  module  testing 

Temporary  Chip  Attach  implementation 

Added  probe  points.  Manual  test  pattern  generation 
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3.4  KNOWN  GOOD  DIE  (KGD) 


3.4.1  Introduction 

One  of  the  major  obstacles  the  MCM  industry  faces  today  is  lack  of  technology  and  infrastructure  to  support 
a  low  cost  KGD  process.  Lack  of  KGD  impacts  MCM  yields,  which  must  therefore  rely  on  a  more  costly 
rework  process  to  produce  a  Known  Good  Module  (KGM).  Unknown  die  quality  also  introduces  added 
complexity  in  module  testing  and  the  diagnostics  process  which  leads  to  unanticipated  higher  costs  for  a 
completed  module.  KGD  is  one  of  the  most  discussed  topics  in  MCM  community  today  because  of  its  key 
role  in  enabling  a  manufacturable  MCM  [10-12,23-25]. 

For  the  ASEM  application,  ADV1  (SUN  MBUS  Super  Cache)  MCM,  the  die  set  (two  logic  and  eight  SRAM 
dies)  were  originally  designed  and  fabricated  for  wirebond  applications.  The  die  were  all  converted  to  a  C4 
type  interconnection.  Because  of  the  complexity  of  the  two  logic  chips  (processor  and  cache  control), 
uncertainty  associated  with  the  C4  conversion  process  and  unknown  die  quality,  a  decision  was  made  to  use  a 
KGD  process  for  all  the  die  used  for  ADV 1 . 

3.4.2  Parameters  for  KGD  Implementation 

The  KGD  process  consists  of  three  major  parts  which  must  be  considered  concurrently: 

(1)  Design  and  fabricate  Temporary  Chip  Attach  (TCA)  modules 

(2)  Chip  attach/detach  processing 

(3)  Chip  testing 

Since  the  test  vectors  for  the  two  logic  chips  were  not  available,  the  decision  was  made  to  use  either  Suns 
ASIC  tester  or  the  Sparc  10  system  box  from  Sun  for  at-speed  functional  test  of  the  large  Super  Sparc  and 
MXCC  ASICs.  The  SRAMs  would  use  an  IBM  developed  memory  tester  for  an  at-speed  functional  test. 

Once  the  test  hardware  was  determined,  the  next  step  was  to  focus  on  designing  the  ceramic  Pin  Grid  Array 
(PGA)  for  the  TCA  module.  The  design  of  the  ceramic  TCA  carrier  for  the  large  ASICs  was  chosen  to 
closely  match  the  physical  parameters  of  the  existing  commercially  available  SCM  packages.  Key  items  of 
similarity  were  the  X,Y  and  Z  dimensions,  pin  length,  pin  diameter  and  pin  layout  which  allowed  the  TCA 
module  to  be  plug  compatible  with  their  commercial  counterparts.  The  design  input  data  was  a  hard  copy  of 
signal-to-pin  connections  provided  by  Sun.  Because  we  did  not  have  a  verified  soft  copy  of  the  netlist  for  the 
ASIC  SCMs,  a  substantial  amount  of  time  was  consumed  manually  checking  the  cross  reference  for  pin 
assignments,  pin  locations,  die  pad  locations  and  die  pad  assignments.  Electrical  analysis  was  performed  to 
ensure  that  the  packaged  chips  would  function  at  the  intended  system  speed  (50  Mhz). 

IBM  Microelectronics  Division  has  developed  two  processes  for  C4  chip  KGD  applications.  [25]  The 
Reduced  Radius  Removal  (R3)  process  has  been  used  as  the  manufacturing  KGD  process  for  internal  KGD 
product  fabrication.  The  second  IBM  developed  KGD  process  provides  a  mechanical  connection  between  the 
die  C4  and  Palladium  dendrites  plated  on  the  pads  of  a  Multilayer  Ceramic  (MLC)  or  Metalized  Ceramic 
(MC)  substrate.  The  integral  heatsink/pressure  plate  ensures  intimate  C4/dendrite  contact  during  chip  bum- 
in  and  test.  The  chip  clamping  fixture  has  an  insert  sued  to  match  the  backside  area  of  the  chip,  as  shown  in 
Figure  3-10  and  is  designed  to  exert  a  controlled  vertical  force  on  the  back  side  of  the  chip.  The  vertical 
force  used  to  hold  the  C4  ball  and  dendrite  pads  together  is  proportional  to  the  torque  applied  to  the  top 
subassembly  center  screw.  The  heat  sink,  which  extracts  heat  from  the  back  of  the  die,  will  dissipate  27  watts 
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of  power  at  an  air  flow  of 400  lfpm  at  30  degrees  C.  The  dendrite  KGD  process  handles  chips  with  higher 
power  than  the  R3  KGD  carrier. 


Figure  3-10:  Temporary  Chip  Attach  Single  Chip  Module  (TCASCM) 


Because  of  the  relatively  high  power  dissipated  by  the  two  logic  dies  (—10  watts)  on  the  ADV1  MCM  and 
considering  that  the  original  Sun  SCM  uses  an  efficient  heat  slug  and  pagoda  heatsink,  we  determined  that  a 
heatsink  had  to  be  used  during  the  chip  test.  Therefore  the  dendrite  TCA  process  was  selected  for  our 
application. 

Once  the  decision  was  made  to  use  the  dendrite  TCA  process  for  the  large  ASICs,  we  decided  to  also  use  the 
process  for  the  SRAMs.  The  TCA  earners  for  the  two  logic  chips  were  designed  using  standard  50mm  Multi 
Layer  Ceramic  (MLC)  technology.  The  TCA  earner  for  the  SRAMs  was  designed  using  standard  28mm 
Metallized  Ceramic  (MC)  technology.  A  process  flow  [25]  for  KGD  temporary  chip  attach  is  shown  in 
Figure  3-1 1 .  Figures  3-12  and  3-13  give  the  schematics  of  substrate  layout  and  list  key  parameters  for  the 
two  logic  TCA.  A  comparison  between  the  commercially  available  SCM  packages  for  the  Super  Sparc  and 
MXCC  and  their  TCA  counterparts  is  presented  in  Tables  3-1  and  3-2. 
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Figure  3-11:  Temporary  Chip  Attach  (TCA)  Process  Flow 
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□  □  JL 

□  50 
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ALL  DIMENSIONS  IN  MM 

S/S  SIZE  50x50 
PIN  #293  (TOTAL) 
VCC(48) 

GND(68) 

SIGNAL(174) 

INDEX(I) 

N/A(2) 


DIE  INF. 

VIKING 

I/O  312  (TOTAL) 
VCC(69) 
GND(69) 
SIGNAL(174) 
10  WATTS 


PIN 

HEIGHT  (5  MM/ 254  MIL) 
DIAMETER  (0.4  MM/ 16  MIL) 


Figure  3-12:  Viking  (Super  Sparc)  TCA  Single  Chip  Module  Layout 
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Figure  3-13:  MXCC  (Cache  Controller)  TCA  Single  Chip  Module  Layout 


MXCC  SCM 


□  □  JL 


□ 

□ 


12.9 

T 

MXCC 

12.9 

D 


3.1 


t=I  O 


50 


50 


SUN  SCM 

ASEMSCM 

^S/S  SIZE  (MM) 

47.24+/-  .45 

50 

PIN  PATTERN 

18x18  +  17x17 

18x18+17x17 

P1N-TO-PIN  PITCH  (MIL) 

100  INTERSTITIAL 

100  INTERSTITIAL 

^PIN  DIA  (MIL) 

*PIN  HEIGHT  (MIL) 

16 

16 

133(180  -  47) 

204(254  -  50) 

TOTAL  PIN# 

293 

293 

VCC 

48 

48 

GND 

68 

68 

SIGNAL 

174 

174 

N/A 

2 

2 

INDEX 

1 

1 

CAVITY  DOWN 

NO  CAVITY 

*  S/S  THICKNESS  (MIL) 

90 

77(7.7X10) 

*  CAP 

COPPER  BLOCK 

ALUMINUM 

*  HEAT-SINK 

*  NOT  THE  SAME 

PAGODA/STUD 

FINNED 

Table  3-1:  Viking  (Super  Sparc)  SCM  Package  Comparison 
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SUN SCM 

*  S/S  SIZE  (MM)  47.24  +A  .45 

PIN  PATTERN  18x18+17x17 

PIN-TO-PIN  PITCH  (MIL)  100  INTERSTITIAL 
PIN  DIA  (MIL)  18 

*  PIN  HEIGHT  (MIL)  133(180  -  47) 

TOTAL  PIN#  369 

VCC  46 

GND  66 

SIGNAL  256 

N/A  0 

INDEX  1 

CAVITY  DOWN 


ASEMSCM 

50 

18x18+17x17 
100  INTERSTITIAL 
16 

204(254-50) 

369 

46 

66 

256 

0 

1 

NO  CAVITY 


*  S/S  THICKNESS  (MIL) 

*  CAP 

*  HEAT-SINK 


90 

COPPER  BLOCK 
PAGODA/STUD 


77(7.7X10) 

ALUMINUM 

FINNED 


*  NOT  THE  SAME 


3.4.3  KGD  Test  and  Conclusion 

SRAM  mounted  on  TCA  earners  were  tested  using  an  IBM  developed  memory  tester.  Standard  memory  test 
patterns  were  successfully  exercised  at  speed  (20ns  cycle.)  However,  the  two  logic  die  were  tested  in  two 
parts. 

1.  Test  the  chip  to  substrate  interconnect  and  associated  circuit  functions  such  as  the  1 149. 1  port,  scan  path, 
and  driver/receiver  functionality  using  the  device  BSDL,  netlist  and  Texas  Instrument's  ASSET  scan  test  tool. 
The  TCA  modules  were  inserted  in  a  special  Low  Insertion  Force  (LIF)  socket  which  matches  the  existing 
SUN  SCM  packages.  The  LIF  sockets  and  the  test  itself  were  baseline  tested  using  commercially  available 
SUN  SCM  for  the  Viking  processor  and  MXCC  cache  controller  die. 

2.  Functionally  screen  the  TCA  die  using  MBUS  circuit  cards  modified  with  LIF  sockets  which  accept  the 
TCA  modules.  The  MBUS  cards  with  the  TCA  modules  are  tested  using  the  power  on  self  test  of  the  Sparc 
10  system  in  which  they  are  embedded.  The  MBUS  cards  w'ere  baselined  as  being  good  using  commercially 
available  SCM  parts. 

Known  good  commercially  available  SCMs  for  the  Viking  and  MXCC  part  numbers  were  used  to  debug  the 
test  process  (hardware  and  data.)  Since  chip  test  was  not  performed  after  C4  bumping,  the  KGD  test  process 
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represented  the  only  means  for  achieving  the  KGD  objective  prior  to  the  module  interconnect  test  Defective 
die  were  sorted  out  and  discarded  before  mounting  to  the  MCM  substrate.  The  combination  of  verified 
BSDL  descriptions  and  die  screening  greatly  reduced  the  uncertainty  of  the  module  test  environment  and 
simplified  module  test  diagnostics.  The  KGD  test  reaffirmed  the  importance  of  the  KGD  assumption  put 
forth  in  the  module  interconnect  test  methodology. 
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3.5  DATA  INTEGRITY 

Introduction 

In  addition  to  Design  For  Test  (DFT)  features  it  is  equally  necessary  to  have  complete  and  correct 
information  for  test  engineers  to  generate  test  files  and  design  test  hardware.  Acquisition  and  maintenance  of 
an  error  free  MCM  data  base  environment  is  a  challenging  task.  The  MCM  database  contains  chip,  substrate 
and  module  information  comprised  of  various  physical,  electrical  and  thermal  characteristics  obtained  from 
several  sources,  both  internal  and  external  to  the  foundry.  In  Section  3.5.1,  we  will  describe  today's  MCM 
infrastructure  and  show  examples  of  why  it  is  difficult  to  achieve  a  defect  free  data  environment  How  we 
have  dealt  with  these  problems  will  also  be  discussed.  We  will  also  show  that  the  additional  costs  incurred  in 
working  through  data  integrity  problems  can  significantly  impact  both  NRE  costs  and  TAT.  Finally  we  will 
present  suggestions  which  may  enable  an  error  free  test  data  environment. 

Data  integrity  problems  [28]  may  stem  from  many  sources  including  missing  or  incomplete  hardware 
descriptions,  incorrect  hardware  descriptions  and/or  nomenclature  mismatches.  The  impact  of  data  integrity 
on  TAT  is  illustrated  in  Figure  3-14.  Time  (and  labor)  added  to  test  file  generation  and  test  debug  due  to  bad 
data  contribute  significantly  to  higher  NRE  cost  and  longer  TAT.  The  figure  compares  the  TAT  for  our  past 
practice  with  two  applications  we  tested  using  the  1 149. 1  methodology.  Each  of  the  applications  used  miysrl 
non-1 149. 1  and  1 149. 1  die  on  the  MCM  and  as  such  was  not  expected  to  compare  exactly  with  the  100% 
1149. 1  goals.  Each  case  required  manual  test  pattern  generation  which  helps  to  account  for  the  amnnnt  of 
time  spent  for  Test  File  Generation  (TFG)  and  debug.  However,  because  of  data  integrity  issues,  only  one  of 
the  applications  met  its  projected  TAT  goal.  The  goals  for  each  area  are  detailed  in  the  Test  Tmplftmftnt^ti^n 
section  of  this  report. 
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Figure  3-14:  Estimates  of  Time  Spent  on  Test  Tasks  (Past,  Actuals,  and  Goal) 
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For  convenience,  we  divide  the  data  integrity  issue  into  two  forms.  The  first  is  associated  with  data;  such  as 
incomplete  data,  data  which  contains  errors  or  unverified  data.  The  second  form  is  associated  with  the  quality 
of  components  such  as  KGD  and  other  hardware  quality  issues.  Since  the  KGD  issue  has  been  discussed 
elsewhere  [9-1 1,23-25],  we  will  focus  discussion  on  data  problems  related  to  device  hardware  descriptions 
rather  than  hardware  quality  specification  issues. 

3.5.1  MCM  Environment 


Examining  the  module  test  process  flow  in  Figure  3-15,  one  will  realize  that  the  complexity  of  module  test 
environment  is  caused  by  the  fact  that  MCM  foundry  deals  with  three  different  kinds  of  products  (chip, 
substrate  and  system.)  In  acquiring  data,  the  foundry  interfaces  with  two  other  types  of  foundries  and  also 
receives  data  from  possibly  three  different  product  design  (EDA)  systems.  In  this  environment  the  MCM 
foundiy  owns  or  controls  only  the  substrate  design,  electrical  parameters,  fabrication  and  test,  and  module 
thermal  design.  Typically  die,  module  and  system  design  are  not  directly  controlled  or  even  connected  to  the 
MCM  foundry.  In  addition,  one  MCM  may  contain  several  different  types  of  die,  which  are  designed  using 
different  design  systems  and  are  fabricated  by  different  die  foundries.  Furthermore,  die  manufacturers  are  in 
general  reluctant  to  release  die  design  information  or  to  change  their  data  structures  and  interface  protocols 
for  economic  or  legal  reasons.  Also  contributing  to  the  complexity  of  the  data  base  environment  is  the 
diverse  skill  base  including  electronic  and  substrate  designers,  thermal  engineering,  assembly  engineering, 
test  engineering,  etc..  Efficient  coordination  of  effort  and  mformation  exchange  between  these  groups 
requires  the  practice  of  concurrent  engineering. 
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Data  integrity  Problems  we  have  experienced  can  be  classified  into  three  categories.  (1)  Inconsistent  data, 
(2)  incomplete  data,  and  (3)  incorrect  data.  Examples  of  the  commonly  occurring  problems  are  listed  in 
Table  3-3. 


(I)  Inconsistent  data: 

(a)  Electrical  (logic)  and  physical  data  do  not  match 

(b)  Substrate,  die  signal  and  pin  (pad)  nomenclature  do  not  match 

(c)  Substrate  schematics  and  netlist  do  not  match 

(II)  Incomplete  data 

(a)  Detailed  thermal  data  for  testing  environment  missing 

(b)  Electrical  data  (such  as  chip  grounding)  for  testing  environment  missing 

(c)  System  Power-up  procedure  for  test  not  completely  defined 

(d)  Chip  Interface  information  missing  (parametrics) 

(e)  Chip  BSDL  information  not  complete 

(III)  Incorrect  data 

i 

(a)  Chip  BSDL  data  incorrect  and/or  not  verified 

(b)  Power-up  procedure  incorrect 

(c)  Versions  of  BSDL  do  not  match  chip  hardware 

Table  3-3:  Classification  of  Data  Integrity  Problems 
Discussion 

As  previously  discussed,  most  of  the  data  integrity  problems  we  have  experienced  are  related  to  the  multi¬ 
design,  multi-product  and  multi-foundry  environment.  Eventually  the  industry  will  overcome  data  integrity 
problems  by  adopting  standards  for  data  interfaces,  data  structures,  KGD  definition,  KGD  quality  assurance 
procedures,  die  descriptions  and  substrate  descriptions.  Work  in  these  areas  is  already  underway  as 
evidenced  by  the  IEEE  1 149. 1  standard,  foundry  EDA  design  kits  [26]  and  other  efforts.  Note  that  even  with 
standards  in  place  the  usage  of  such  standards  will  require  experience  and  agreement  between  concerned 
parties  regarding  interpretation  and  actual  practice.  In  the  mean  time,  we  have  derived  and  practice  a 
methodology  which  reduces  the  occurrence  of  data  integrity  problems  and  minimi  the  impact  of  existing 
data  integrity  problems. 
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3.5.2  Data  Integrity  Methodology 

1.  A  single  interface  between  the  foundry  and  customer. 

By  a  single  interface  we  mean  a  focus  person  who  will  log  and  distribute  information  and  materials  as  well 
as  coordinate  technical  contacts.  More  importantly,  we  also  mean  the  customer  will  be  responsible  for  chip 
mformatron  mput  to  the  foundry  as  described  in  [27]  rather  than  the  foundry  acquiring  chip  information  from 
a  thrrd  parly  vendor.  The  use  of  a  single  interface  forces  coordination  of  effort  and  facilities  data  tracking 
data  revision  control  and  timely  data  distribution.  Information  distribution  controls  are  important  for  an  error 
free  data  system  and  for  the  protection  of  intellectual  property  rights  between  the  foundry  and  customer. 

2.  The  MCM  foundry  defines  the  foundry/customer  interface. 

The  interface  includes  assignment  of  technical  resources,  business  procedures,  process  flow/logistics  and 
requirements  for  customer  supplied  data.  A  description  of  the  customer  interface  environment  and  an 
example  of  a  test  data  requirement  worksheet  used  for  module  test  are  given  in  Figures  3-16  and  3-17 
respectively.  The  worksheet  is  modified  for  a  specific  product  and  clearly  defines  what  information  the 
customer  and  other  groups  in  the  foundry  must  provide.  The  worksheet  is  defined  during  the  product 
definition  phase  and  is  reviewed  at  the  completion  of  module  design. 

3.  Chip  information  is  supplied  from  the  customer. 

With  the  exception  of  foundiy  supplied  chips,  all  chip  related  information  is  acquired  from  the  chip  supplier 
by  the  customer.  The  chip  data  is  then  forwarded  to  the  MCM  foundry  after  resolution  of  revision  and 
naming  conventions.  Lead,  pad  or  net  names  must  be  in  agreement  with  both  supplied  physical  drawings 
schematics  and  test  data. 

4.  Electronic  or  soft  data  exchange. 

This  practice  helps  to  minimize  errors  caused  by  manual  transcription. 

5.  Database  management. 

A  system  which  enables  all  correspondence  and  data  to  be  revision  controlled  and  accessible  on  a  need  to 
know  basis  by  engineers  and  designers.  A  key  document  in  this  system  is  a  "history"  file  which  contains  a 
summary  of  engineering  and  design  changes.  The  data  management  system  is  a  key  element  in  facilitating  a 
concurrent  engineering  environment.  "  0 

6.  Data  and  Netlist  verification. 

Before  we  reach  a  error  free  data  exchange  environment,  test  data,  such  as  BSDL,  netlist,  power-up 
procedures,  schematics  and  lead/pin  nomenclature  are  verified  before  prototype  MCMs  are  available  in  order 
to  minimize  the  unpact  of  data  and  hardware  debug  on  planned  MCM  delivery.  Verification  of  hardware 
descriptions  against  hardware  can  be  performed  by  utilizing  prototype  printed  circuit  boards(brassboard) 
which  are  built  by  system  designers  as  design  verification  tools.  Single  Chip  Modules(SCM)  and/or 
Temporary  Chip  Attach(TCA)  SCMs  can  also  be  developed  to  debug  test  fixture  hardware,  BSDL 
descriptions,  test  vectors  and  test  procedures.  This  practice,  though  effective  at  helping  to  keep  the  TAT  low, 
is  labor  intensive  and  adds  directly  to  the  NRE  cost  of  a  prototype  MCM. 

7.  Quantify  added  NRE  costs  due  to  data  integrity  problems 

We  believe  that  the  most  effective  way  to  solve  the  data  integrity  problem  is  to  directly  tie  MCM  prototyping 
costs  with  quality  of  data.  Quantifying  the  cost  savings  associated  with  error  free  data  exchange  can  provide 
leverage  for  resource  allocation  directed  at  standards  development  and  implementation  as  well  as  internal 
business  process  improvements  for  both  the  foundiy  and  its  customers.  Such  improvements  to  TAT  and  cost 
will  encourage  more  system  designers  to  use  MCMs  as  their  packaging  solution.  The  foundry  should  develop 
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1°  ^  w St  associated  with  bad  data  to  the  source  of  the  information  and  resolve  the  cause  of 
the  data  integrity  problem  as  early  as  possible. 


FOUNDRY 


ELECTRONIC 

DATA 

EXCHANGE 

SINGLE  POINT 
INTERFACE 


BACK  ANNOTATE 


CUSTOMER 

a  MODULE  LEVEL  INFORMATION 

TT  EDIF  SCHEMATIC 

MCM  ELECTRICAL  SPECIFICATIONS 
MCM  PHYSICAL  SPECIFICATIONS 

DIE  LEVEL  INFORMATION 
J  DIE  (physical) 

TT~  DIE  INTERFACE 
BSDL 

CONSISTENT  NOMENCLATURE 


Figure  3-16:  Test  Data  Customer  Interface 


Documentation  is  provided  to  the  customer  which  provides  a  measure  of  costs  incuired  in  fixing  the  data  they 

flSlCM  FTlB  .dOCUmen,?ion  htoded  >»  M> 1“  customer  lower  their  NRE  costs  for 

WmMCM  jKOtoftppB  NRE  savings  provide  motivation  for  the  customer  to  improve  their  data  handling 

ETt^f  OT  P  kVeraSe  a8ataSt  <lKir  cUp  supp“'rs  t0  taprove  “suracy  “d  scope  of  Chip 
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Test  Data  Requirements 


General  requirements: 

*  All  Data  provided  in  softcopy  form.  (Schematics  and  data  sheets  are  acceptable  in  hardcopy  but  are  preferred  in 
softcopy) 

■  TIME  and  DATE  stamped.  Revision  number  and  source(who) 

■  Signal  /  Lead  names  <=  6  characters 

■  If  nomenclature  differs  for  lead,  signal  or  net  name  between  schematics,  data  sheets  or  BSDL  then  a  global  cross 
reference  must  be  provided. 

The  following  supports  1 149. 1  based  bond  and  assembly  verification  test.  Please  check  off  items  supplied  and  note  the 
format. 

3  .Validated  BSDL  for  each  1 149. 1  compliant  die. 

□  Validation  provided  by  ALC _ . 

□  BAREJDEE  PHY  SIC  AL_PIN_MAP  description  included. 

2.  NETLIST 

□  Allegro  format  (ALC) 

□  EDEF  (netlist)  format  (ALC  optional) 

(note  this  is  different  from  the  ibm  foundiys’  "EDEF  schematic"  entry  format) 

□  External  physical  design  entiy(eg.  in  GL1) 

□  other  industry  standard  entry  (describe) 

3.  NON-1 149. 1  die  interface  description 

□  Active  die  (ALC  ,  FPGA  and  EEPROM) 

□  Passive  die  (IBM,  0805  capacitor) 

4. Physical  schematics 

□  Die  (ALC ,  FPGA  and  EEPROM  [  preliminaiy  drawings  received  already]) 

□  MCM  (ALC  [  preliminary  layout  drawings  received  already]  IBM  to  provide  final  MCM  dimensions) 

5.  Electrical  schematics 

□  Die  (ALC,  active  die  terminal  characteristics  only ) 

□  MCM  Signal  Architecture  (ALC) 

□  MCM  electrical  schematic  (ALC) 

6.  Thermal  data 

□  Die  (From  data  sheets) 

□  MCM  level(ALC) 

7. Module  I/O  specification 

□  PIN  FUNCTION /NAME  DESCRIPTION 

-Must  account  for  all  MCM  leads  by  function(eg.in,out,bidi(system  controlled) 
tristate(l  149.1  controlled),  VCC(volts),  GND,  TAP,  CLK,  fixed  value,  or  other... 

□  Safe  Power  on  /  power  off  sequence 
-Must  account  for  all  MCM  leads 

8. Cross  reference 

□  Net,  signal,  lead  name  listing  providing  name  equivalence 

Figure  3-17:  Example  of  Foundry  Test  Data  Interface  Worksheet 
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3.5.3  Data  Integrity  Conclusion 

Low  cost  and  quick  TAT  MCM  product  development  depends  on  error  free  data  exchange  environment  The  lone 
term  solution  to  the  data  integrity  problem  can  only  by  achieved  by  establishing  a  standard  data  exchange 
mteiface  and  data  management  system.  The  key  to  effective  implementation  relies  on  the  foundry's  ability  to 
quantify  the  cost  associated  with  quality  of  data  and  the  ability  to  show  MCM  users  that  poor  data  input  to  the 
foundry  contabutes  directly  to  higher  NRE  costs  and  longer  TAT.  In  the  short  term,  a  precisely  defined  interface 
structure,  disciplined  date  control  system,  and  data  verification  procedures  help  to  minimize  the  impact  of  data 
integrity  problems  on  NRE  costs  and  TAT.  p 


3-38 


3.6  MCM  CASE  STUDIES 

3.6.1  Demonstration  Vehicle  Test  Summary 

The  information  presented  in  this  section  will  be  related  primarily  to  how  well  the  case  studies  met  the 
requirements  and  assumptions  as  presented  in  the  methodology  section  of  the  MCM  Test  report.  The  two 
case  studies  are  reported  in  detail  in  Section  6  of  the  report.  The  information  is  presented  in  Table  3-4  and 
shows  which  methodology  assumptions  were  met.  The  impact  of  deviations  from  the  assumptions  on  NRE 
cost  and  turn  around  time  is  presented  as  a  form  of  benchmark  data  in  the  second  part  of  this  sectioa 


ASSUMPTIONS 

SUN  SPARC  MCM 

MCCLELLAN  ALC  DTM 
(Data  Transfer  Module) 

Netlist 

Yes 

Data  integrity  problem 

Yes 

KGS 

Yes 

Yes 

KGD 

No 

Yes 

1149.1 

Yes 

Yes 

<  100% 

<  100% 

BSDL 

No 

No 

Minor  data  integrity  problem 

Functional  Test 

No 

No  support  effort 

Yes 

Table  3-4:  Methodology  Assumption  Adherence  Comparison  -  ADV1  versus  ADV2 


The  functional  test  plan  plays  a  key  role  in  enabling  not  only  a  module  level  test  but  impacts  the  outcome  of 
key  requirements  for  module  interconnect  test  such  as  KGD,  KGS,  and  data  (such  as  BSDL  and  netlist) 
integrity.  Commitment  to  develop,  simulate  and  perform  appropriate  functional  tests  at  the  die  and  module 
level  enhance  the  likelihood  of  successful  designs  on  the  first  pass. 

3.6.2  Benchmark  Results 
3.6.2.1  Test  Process  Components 

In  order  to  quantify  and  track  planned  improvements  to  NRE  costs  and  TAT,  the  test  process  was  broken 
down  into  significant  areas  as  illustrated  in  Figure  3-18.  TAT  benchmarking  data  is  reported  in  Figure  3-14 
for  fixturing.  Test  File  Generation  (TFG),  debug  and  test.  The  TFG  categoiy  combines  both  automatic  test 
file  generation  and  manual  test  pattern  generation  activities.  The  customer  interface,  test  plan  and 
diagnostics,  concern  initial  customer  contacts,  premanufacturing  planning  and  test  failure  diagnostics 
respectively.  Improvements  to  our  customer  interface  process  have  been  made  based  on  a  refined 
knowledge  and  communication  of  data  requirements  through  the  use  of  test  data  requirements  checklists 
which  are  used  during  the  Request  for  Quote  (RFQ)  and  foundry  entry  process.  The  customer  interface 
process  has  further  been  improved  by  providing  customers  with  test  guideline  and  test  definition 
documentation.  Test  plan  development  has  been  streamlined  by  carefully  defining  the  services  and 
capabilities  of  the  foundry  test  group  and  then  mapping  customer  requirements  to  the  capabilities. 
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CUSTOMER 


Figure  3-18:  Test  Process  Components  for  Benchmarking 


3.6.2.2  MCM  Test  Benchmark  Data 

Figure  3-14  reports  benchmarking  data  for  two  Application  Development  Vehicle  (ADV)  MCMs  and 
compares  &e  resulting  engineering  time  to  an  estimate  of  our  previous  practice  and  to  our  goal  for  each 
activity.  Detailed  descriptions  of  the  two  ADVs  are  presented  in  Section  6  of  the  report. 

ffexttT 5?  “  M,CM  flXtUring  f0F  t£St  NRE  md  TAT  reductions  have  bee*  implemented  using  a 

S  n  J 5STd  ft  managTnt  SCheme-  ^  g0al  “  desi8“  «*»  integration  of  the  fixture  is  to 

spend  no  more  than  2.5  engineering  days  on  this  activity.  The  current  process  time  for  daughter  card  design 

and  fabrication  is  approximately 'four  weeks,  which  can  be  improved  if  necessary,  using  a  quick  turn  aroufd 
CB  fabrication  service.  Since  the  daughter  card  process  time  fits  within  the  MCM  substrate  fabrication 
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schedule  and  thereby  does  not  gate  the  MCM  delivery  schedule,  the  lower  cost  regular  TAT  PCB  fabrication 
service  is  used  whenever  possible. 

Reductions  in  the  amount  of  engineering  NRE  and  TAT  for  Test  file  generation  have  been  accomplished  by 
using  a  commercially  available  ATPG  software  package.  The  base  processing  time  for  the  ATPG  portion  of 
the  test  file  generation  time  can  be  quite  low.  But  for  the  case  of  the  two  ADVs,  it  also  includes  the 
engineering  time  for  manual  test  pattern  generation.  Raw  process  time  for  test  file  generation  is  only  slightly 
greater  than  the  amount  of  engineering  days  consumed.  Suggestions  for  improvements  to  the  software,  which 
improve  its  utility  and  help  to  shorten  manual  test  serialization  times,  have  been  communicated  to  the 
software  vendor  for  further  product  enhancements.  Additionally,  the  foundry  has  been  serving  as  a  Beta  test 
site  for  future  release  versions  of  the  Teradyne's  Victoiy  ATPG  software  package. 

Debug  is  the  most  variable  component  of  the  benchmark  activities  and  tends  to  add  significantly  to  NRE  if 
the  test  data  provided  to  the  foundry  is  not  correct.  The  goal  of  2.5  engineering  days  spent  on  test  data 
verification  and  debug  of  the  tester  fixturing  is  estimated  based  on  100%  correct  input  data  to  the  process. 
Recognizing  that  this  often  may  not  be  the  case,  the  original  selection  of  a  standard  test  methodology  greatly 
reduces  the  learning  curve  associated  with  each  new  part  number.  A  firm  understanding  of  the  1 149. 1  test 
standard  and  its  application  helps  to  minimize  the  time  required  to  pin  point  errors  in  hardware  descriptions 
or  other  associated  data  and  in  this  regard  has  already  proved  itself. 

The  final  benchmark  category  is  the  test  itself.  While  our  goal  in  this  case  is  the  same  as  our  previous 
practice  (see  Figure  3-14),  we  felt  it  is  important  to  monitor  the  time  spent  to  ensure  we  were  meeting  our 
TAT  commitments.  This  is  important  because  in  the  process  schedule,  particularly  for  the  first  prototype 
parts,  fixture  debug  and  test  are  concurrent  activities  which  may  directly  impact  the  committed  MCM 
delivery  date.  Our  data  shows  we  were  able  to  meet  our  commitments  without  adversely  affecting  final  MCM 
e  very.  However,  the  ability  to  meet  the  test  time  goal  was  paid  for  bv  more  engineering  time  spent  in  up¬ 
front  test  file  generation  and  data  verification  activities  associated  with'the  fact  that  we  did  not  have  an  error 
tree  data  interface/exchange  system. 
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3.7  MCM  TEST  CONCLUSIONS 


A  module  test  methodology  for  low  NRE  cost  and  fast  turn  around  time  ASEM  applications  has  been 
developed.  The  methodology  was  implemented  in  the  IBM  Microelectronics  Division  foundry  to  provide 
service  for  OEM  applications.  The  methodology  has  been  applied  to  two  ARPA  ASEM  funded  application 
MCMs  and  several  other  OEM  customers.  We  believe  that  the  ASEM  objectives  for  module  test  are 
achievable.  However,  the  module  test  plan  developed  must  strictly  follow  the  methodology  guidelines: 

♦  Assumption  Conditions  Met 

I.  KGD  and  KGS 

II.  Good  BSDL,  netlist  and  module  data 
Design  for  Test 

I.  Die  -  Sufficient  mix  of  1 149. 1  die  to  enable  high  coverage  interconnect  test 

II.  Substrate  -  Add  test  and  control  points,  check  electrical  impact 
IE.  Staged  assembly  of  prototypes 

♦  Distributed  Test 

I.  Substrate  Test 

II.  Interconnect  test 

III.  Chip  Internal  test  -  as  required  for  MCM  die-by-die  test 

IV.  Module  functional  self  test  -  by  foundiy  if  implemented 

V.  Functional  test  -  by  customer 

♦  Data  Integrity  Conditions  Met 

I.  Standardized  customer  interface  documents 

II.  Design  review  checks 

♦  Design  and  Data  Verification 

I.  Prototype  printed  circuit  board  verification 

II.  Simulation  -  by  customer 


The  MCM  test  challenge  should  become  easier  over  time,  due  to  the  following  trends: 

♦  Broader  1 149. 1  compliance,  for  both  logic  and  memory  chips 

♦  Wider  availability  of  Known-Good  Die 

♦  Improved  EDA  support 

The  effect  of  these  improvements  will  be  to  focus  attention  away  from  the  solved  problem  of  interconnect  and 
BIST  testing  mto  functional  test  improvements.  Essential  to  cost-effective  functional  testing  is  the  ability  for 
the  EDA  system  to  operate  on  hierarchical  representations  of  the  MCM.  For  instance,  it  should  be  possible 
to  generate  and  simulate  patterns  using  a  model  of  the  MCM  in  which  the  MCM  is  described  in  a 
combination  of  VHDL,  BSDL,  and  gate  level  descriptions.  Further  development  work  is  needed  in  various 
aspects  of  hierarchical  test  generation  [21],  including;  propagation  of  interconnect  fault  models  through 
behavioral  descriptions;  behavioral  fault  models;  behavioral  test  generation;  hierarchical  extraction  of  MCM 
tests  from  system  design  verification  patterns;  behavioral  level  delay  fault  models;  performance  pattern 
coverage  metrics;  diagnosis  oriented  test  pattern  generation. 
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4.0  C4,  WIRE  BOND,  AND  TAB  INTEGRATION 

As  an  ASEM  foundry,  IBM  recognizes  the  need  to  produce  MCM's  that  incorporate  flip  chip  wire  bond 
and  tape  automated  bonding  (TAB)  die  attach  technologies.  IBM  MCM  products  have  traditionally  used 
solder  flip  chip  ( i.e.,  C4  )  as  the  primary  means  of  die  attach  whereas  the  overwhelming  majority  of 
singe  chip  products  have  used  wire  bond  or  TAB.  Thus,  the  primary  goal  in  Task  2.2. 1  is  to  demonstrate 
all  three  die  attach  techniques  on  a  single  module.  On  a  larger  scale,  the  task  supports  the  overall  project 
goal  of  making  the  IBM  East  Fishkill  foundiy  accessible  to  external  customers  ( both  military  and 
commercial).  This  includes  not  only  incorporating  external  devices,  but  also  developing  and  exercising 
processes  that  reduce  both  the  turn  around  time  and  cost  for  MCM  manufacturing. 

This  section  discusses  the  test  vehicle  created  to  demonstrate  the  interconnection  technology,  the  physical 
analysis  of  the  test  vehicle,  and  the  cost  reduction  practices  developed  with  this  vehicle. 
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4.1  MCM  TEST  VEHICLE(TECHNOLOGY  DEMONSTRATION 
VEHICLE) 

4.1.1  MCM  Test  Vehicle  -  Methods 

The  build  of  the  Technology  Demonstration  Vehicle  (TDV)  substrate  was  a  multi-step  process.  It 
consisted  of  a  technology  survey,  process  flow  definition,  design,  fabrication  and  assembly.  Methods  for 
each  of  these  are  described  below. 

The  ASEM  program  was  geared  primarily  toward  the  MCM-D  type  substrate,  which  consisted  of 
deposited  dielectric  and  metal  thin  films.  At  the  time  of  project  start-up,  four  thin  film  processes  were 
available  at  the  IBM  East  Fishkill  site.  Each  process  was  capable  of  producing  a  one-plane-pair  structure 
( 5  metal  layers)  with  a  50  ohm  characteristic  impedance.  All  four  processes  were  thoroughly 
investigated,  and  their  strengths  and  weaknesses  were  noted.  The  process  chosen  was  the  one  that  closely 
resembled  that  used  to  fabricate  the  MCM  for  the  IBM  ES-9000  mainframe,  i.e.,  a  polyimide  dielectric 
with  copper  conductor  that  is  defined  by  subtractive  etching.  Although  this  process  had  not  been  used  for 
a  qualified,  non-planar  thin  film  vehicle,  it  was  felt  that  it  would  be  most  successful.  Also,  the  clean-room 
facility  would  be  available  within  the  time  frame  needed  for  the  project. 

Once  the  technology  was  defined,  a  preliminary  process  flow  was  assembled.  It  was  decided  that,  for  the 
projected  design  groundrules,  the  first  four  metal  layers  would  be  fabricated  by  subtractive  etching,  i.e., 
sputter  deposit  the  full  thickness  of  the  conductor  and  etch  away  the  unwanted  regions.  Because  of  the 
unique  nature  of  the  top  surface  metallurgy  (see  Section  4.3.1 ),  evaporation  would  be  required.  This 
process  flow  was  consistent  with  that  available  in  the  foundry  at  the  time. 

The  initial  process  flow  and  preliminary  conceptual  design  for  the  TDV  were  presented  to  Dr.  Naclerio  in 
February,  1993.  After  review,  both  required  alteration.  Specifically,  Dr.  Naclerio  requested  that  a  finer 
pitch  TAB  die  and  plate  up  processing  be  incorporated.  Both  of  these  were  accomplished.  The  TAB  die 
(see  Section  4.1.2 )  was  purchased  from  Microelectronics  and  Computer  Technology  Corporation.  Plate 
up  processing  was  scheduled  to  be  available  in  the  fourth  quarter  of  1993.  However,  this  was  accelerated 
into  the  third  quarter  to  accommodate  the  TDV.  To  gauge  a  comparison  of  subtractive  etching  with  plate 
up,  we  decided  to  fabricate  the  TDV  with  the  first  two  metal  layers  ( MO  and  Ml)  with  subtractive 
etching,  the  second  two  (M2  and  M3)  with  plate  up,  and  the  top  surface  by  evaporation. 

In  support  of  the  overall  project  objectives,  it  was  decided  that  the  TDV  should  be  designed  using 
Cadence  Design  Systems  Allegro-E  software.  If  successful,  this  would  signal  that  the  foundry  could 
accept  an  external  design  done  with  the  software.  The  C4  and  wire  bond  test  chip  portion  of  the  TDV 
design  was  taken  from  an  existing  IBM  ceramic  test  vehicle.  A  new  design  was  used  for  the  TAB  die. 

Each  of  the  test  die  was  a  passive  device,  i.e.,  no  active  circuits.  An  initial  design  was  completed  and 
reviewed  with  RELTECH.  After  the  review,  it  was  decided  that  an  active  circuit  ( a  ring  oscillator )  and 
several  thin-film  diagnostic  features  should  be  added. 

Once  the  design  was  completed,  preparations  for  manufacturing  were  begun.  It  was  decided  that  the  TDV 
should  be  built  as  4  pieces  per  laminate.  An  alignment  scheme  was  designed  such  that  any  multi-up 
vehicle  (  2  or  more  pieces  per  127mm  laminate )  could  be  built  with  that  scheme  (see  Section  43.2). 

Next,  all  required  fixturing  for  the  processing  was  built.  Laminates  were  released  to  the  thin  film  foundry 
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period  of  three  weeks  during  August.  1993.  The  foundry  processed  the  TDV  substrates  in  a  class  100 
clean  room  environment. 

Because  of  the  mixture  of  interconnection  methods  (  C4,  W/B,  TAB ),  it  was  necessary  to  develop  a 
process  flow  for  module  assembly  (see  Figure  4-1).  It  was  required  that  a  thermal  hierarchy  be  devised 
that  would  allow  solder  processes  to  be  completed  before  wire  bonding  or  lasersonic  T AB  attach.  For  the 
C4  process,  a  flux  was  applied  first  and  die  placement  was  done  using  a  manual  die  placement  tool.  The 
module  was  then  placed  into  a  belt  furnace  to  flow  the  solder.  After  solder  flow,  the  module  was  subjected 
to  flux  cleaning  in  90  °C  xylene.  For  the  wire  bond  and  TAB  processes,  a  silver-filled  die  attach  material 
was  first  dispensed  onto  the  die  attach  area.  Next  the  die  was  placed  using  approximately  600  grams  of 
force.  The  module  was  then  placed  in  a  box  furnace  to  cure  the  die  attach  material  (150°  C,1  hour).  The 
wire  bond  electrical  connections  were  made  by  an  automatic  tool  using  the  wedge  bonding  technique. 

Al/Si  (1%)  wires  0.00125  inch  diameter  were  used.  The  TAB  electrical  connections  were  tnaHg  ncing 
lasersonic  bonding  to  attach  the  outer  leads.  These  connections  wrere  done  primarily  on  an  automatic 
tool,  however,  a  manual  tool  was  used  on  leads  which  had  incoming  alignment  defects.  The  die  attach 
processes  were  done  in  a  class  10,000  pilot  bond  and  assembly  facility . 


FLIP  CHIP  (C4) 
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FLUX  APPLY 
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OUTER  LEAD 
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Figure  4-1 :  Module  Assembly  Process  Flow 


In  order  to  facilitate  electrical  testing  and  environmental  stressing,  it  was  necessary  to  design  a 
hermetically  sealed  carrier  for  the  TDV.  The  design  process  was  similar  to  that  described  for  the  TDV 
substrate  although  it  was  evident  a  priori  that  the  carrier  would  be  strictly  multilayer  ceramic.  A 
technology  survey  was  done  to  determine  the  best  sealing  method.  Once  the  sealing  method  was  chosen, 
the  process  flow  was  automatically  defined.  The  design  was  accomplished  quickly  using  the  Allegro  E 
software.  The  finished  carrier  was  72mm  square  and  incorporated  a  70mm  square  Kovar  metal  lid  for 
sealing.  This  lid  size  was  the  largest  ever  attempted  for  Kovar  in  the  foundry.  The  sealing  method  used 
was  one  in  which  only  the  edges  of  the  carrier  were  heated  (seam  sealing).  Due  to  the  large  lid  size,  it  was 
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5^ StfP,°fthe  m,°dule  aSSembly  Process  was  to  the  finished  substrate  (after  die  attach)  to  the 

ceramic  as  if  it  were  a  large  wire  bond  die.  After  the  die  attach  material  was  cured!;  the  bonds  were  made 

q™S  °n  ^  substratesand  those  on  the  carrier  (Au  ball  bond,  0.001 "  wire).  The  carrier  is  heated 
to  150  C  for  this  operation.  The  wirebonds  are  then  inspected  after  which  the  lids  are  attached  The 
above  process  was  done  m  the  Interconnection  Development  facility  in  the  foundry. 

After  the  completion  of  seam  sealing,  the  modules  were  characterized  electrically.  For  the  testing  a  10 
mA  current  was  used  on  Ac  test  chips,  and  a  100  mA  current  was  used  on  the  vk  resto^lSre 

4.1.2  MGM  Test  Vehicle  -  Results 

S“S  h  TabIe  4A  “d  a  cross  sectional  view  is  shown  in 
Figure  4-2.  The  TDV  was  designed  with  groundrules  for  a  50  ohm  characteristic  impedance  To  achieve 

a  twctee^n  ?°SS  **  C°PP‘2^  3  thickness  of  5  microns-  The  dielectric  layers  are  polyimide  with 

a  thickness  of  12.5  microns.  The  devices  attached  to  the  substrate  are  described  below: 

tIEST  DIEi1  PCr  ?ubsfate)  ‘ Tbe  TAB  die  is  a  328  lead  test  vehicle  obtained  from  MCC 
Bom  the  inner  and  outer  lead  bond  pitches  are  0.004"  (0. 102  mm)  and  the  leads  are  0.002" 

(  .  51mm)  wide.  The  die  has  a  quadruple  track  over  most  of  it's  area  and  daisy  chain 

•r0sperimeter- 

SR  TE^  DIfo(2  PCr  SUbStrate) ' 7,16  vvire  bond  die  is  a  9.4  mm  test  vehicle  built  by 

M  Burlington  and  has  280  I/O.  The  die  pads  are  0.1 00  mm  square  on  a  0.200  mm  pitch  The7 

OiTn?  rnf™™heaterS  8  WattS  P°Wer  dlSSipation)’  temPerature  sensors,  and  daisy  chains  at 

n mm?  c°nneatl0n  1S  a  wed§e  bond  to  die  substrate  with  Al/Si  (1%)  wire  that  is 
U.U0125  (0.032  mm)  in  diameter. 

substrate)  -  The  C4  die  is  a  13  mm  test  vehicle  built  by  IBM  Burlington 
and  has  24011/0  (not  fully  populated).  The  solder  balls  are  0. 125  mm  in  diameter  on  a  0.250 
rnmpitch  (a  high  Pb/Sn  alloy).  The  solder  balls  are  all  connected  on  the  die 
•  OCTAL  INVERTER  (WIREBOND)  DIE  (2  per  substrate)  -  He  octal  inverters  are  the  only 
acnyeAceonttosnbshnte.  Theyare  1.9x28mn,with0,100mmsqnarebondpads.  Theyare 

by  “!dSe  bondf8'  1116  *wo  **  separated  by40mmandarewiredto<S* 
other  through  the  substrate  to  fonn  a  ring  oscillator  circuit.  The  oscillation  frequency  is  5  MHz. 

?IT?V,CT,fr  1S  Sh0Wf  (schematically)  in  Figure  4-3.  It  consists  on  10  layers  of  alumina  ceramic 

elec t  fT  3  met31  Paueu  screened  onto  ^d  is  sintered  together.  The  carrier  provides  an  ’ 
electrical  path  from  pins  on  the  bottom  side  (which  plug  into  a  socket)  to  wirebond  padson  the  top  side 

Aftditiondly,  a  2  mm  wide  seal  band  is  provided  on  the  top  surface  for  brazing  a  70  mm  square  Kovar  lid 

^  50im  3  ^ 111111 3iray  0n  2  54 110111  centers  (625  total).  The  TDV  substrate  is  joined  using  a 
standard  die  attach  material  Au  bonding  is  used  to  make  the  electrical  connections  (0.001"  wire) 
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TECHNOLOGY: 

Thin  films  (Cu/Polyimide),  60  mm  square 

5  Metal  Layers  (2  subt.  etch,  2  plate-up,  evap.  TSM 

Alumina  base  (1.5  mm  thick) 

WIRING: 

0.025  mm  signal  lines,  0. 1  mm  pitch  (200  cm/cm2) 

0.015/0.050  mm  diagnostics 

INTERCONNECTION: 

C4  (flip  chip),  wirebond,  TAB  (lasersonic) 

Wire  bonded  to  ceramic  carrier  (or  cavity) 

Staple  bonds  (microconnection) 

552  I/O  (edge  pads) 

DEVICES: 

4  passive,  2  active  dice 

Discrete  capacitors 

DIAGNOSTICS: 

Transmission  lines 

Capacitors  (intra  and  inter-layer) 

Via  resistivity 

TSM  Adhesion 

Intentional  line  defects 

PACKAGING: 

10  -  layer  alumina,  1.5  mm  thick,  72  mm  square 

Kovar  lid  (peaked  at  center),  0.0 10"  thick 

Au/Sn  braze,  seam  sealed  (hermetic) 

625  I/O  pin  grid  array 

I  able  4-1 ;  Technology  Demonstration  Vehicle  Description 

As  mentioned  previously,  both  the  substrate  and  the  carrier  required  some  development  work  in  order  to 
achieve  a  cost  reduced  process.  For  the  substrate,  three  of  these  cost  reductions  are  described  in 
Section  4.3.2.  In  addition  to  the  cost  reduction  achievements,  the  TDV  was  the  first  vehicle  built  in  the 
high  volume  foundiy  with  plate  up  processing.  Plate  up  processes  had  been  previously  developed,  but  not 
transferred  to  the  factory.  The  process  transfer  was  made  for  the  TDV,  however,  differences  in  the  tool 
sets  (between  development  and  manufacturing  facilities)  and  the  large  active  area  resulted  in  a  significant 
amount  of  additional  development.  One  example  of  this  was  the  need  to  define  a  completely  new  set  of 
exposure  and  photoresist  development  parameters.  Initially  this  resulted  in  a  high  degree  of  rework  and 
substantial  yield  loss,  however,  once  the  necessary  development  took  place  the  substrates  were  processed 
with  much  higher  yields  and  confidence.  The  majority  of  yield  loss  occurred  in  the  first  plate-up  layer 

(signal -X).  The  second  plate-up  layer  was  processed  smoothly  and  with  high  yield. 
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The  TDV  earner  also  required  some  development  in  order  to  attach  the  lid  and  form  a  hermetic  seal  As 
mentioned  earlier,  the  metal  lid  was  the  largest  ever  used  in  the  foundry.  The  development  work  involved 
optimizing  the  design  and  process  parameters  simultaneously.  In  particular,  the  lid  and  braze  preform 
thicknesses  were  varied  to  allow  flexibility  during  seam  sealing.  The  seam  seal  parameters  (power,  feed 
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rate)  were  varied  until  a  reliable  hermetic  seal  could  be  obtained.  The  results  showed  that  the  most 
reliable  seals  were  obtained  with  a  lid  thickness  of  0.010",  peaked  along  one  axis  to  minimize  "oil 
canning  ,  and  a  braze  preform  thickness  of  0.0048"  attached  to  the  lid.  The  most  relevant  seam  sealing 
parameters  were  a  power  of  1500  Watts  and  a  feed  rate  of  60  inches/minute.  Leak  rates  of 
8  E-10  atm-cc/sec  of  helium  (measured  after  12  hours  bombing  at  45  psi  He)  were  obtained  using  these 
parameters^  Although  oil  canning  was  not  eliminated  totally,  it  was  controlled  well  enough  to  allow  a 
clearance  of  at  least  0.5  mm  between  the  bottom  of  the  lid  and  the  highest  wire  bond. 

Because  theTDV  incorporated  three  types  of  die  interconnection,  a  process  flow  for  joining  had  to  be 
developed.  The  final  process  flow  is  shown  in  Figure  4-1.  In  developing  it,  the  thermal  requirements  of 
each  process  were  taken  into  account.  The  higher  temperature  processes  being  exercised  first.  All  of  the 
modules  received  the  C4  test  die,  which  involved  a  thermal  excursion  to  over  300°  C.  For  the  substrates 

r™l™/caPacitors>  ?*  S°Ider  W3S  fl0Wed  onto  pads  during  the  C4  cycle,  and  the  capacitors 

attached  m  a  second,  lower  temperature  reflow.  Next,  the  Ag  filled  die  attach  material  was  dispensed  and 
wire  ond  and/or  TAB  dice  were  placed.  After  die  placement,  the  substrates  were  annealed  at  150  °C 
to  cure  the  attach  material.  Each  substrate  experienced  one  or  two  or  these  cycles.  Wirebonding  and 
lasersomc  TAB  were  done  pnor  to  the  joining  of  the  substrate  to  the  carrier.  The  substrate  is  then  placed 
onto  the  earner  as  if  it  were  a  large  wirebond  die.  The  final  steps  are  an  inspection,  earner  wirebonding, 
and  module  sealing.  Verification  of  the  entire  process  was  gained  by  electrical  and  physical  testing. 

The  foundry  delivered  82  electrically  viable  TDV  substrates  and  85  carriers.  Additionally  22 
mechamcaUy  good  substrates  were  delivered.  Of  the  104  total  substrates,  96  received  all  three  types  of 

7ht  VlablC  s"bstTates  were  bonded  t0  carriers.  From  the  77, 40  substrates  were 

shipped  to  RELTECH  for  use  m  their  testing  program.  The  others  were  used  for  the  electrical  and 
physical  testing  described  in  section  4.2. 

Another  foundry  "first"  was  that  both  the  TDV  substrate  and  carrier  were  deigned  with  Cadence  Design 
Systems  Allegro-E  software.  The  substrate  design  was  completed  first.  It  took  approximately  2  man- 
months  longer  that  the  anticipated  time  which  was  based  on  the  IBM  internal  design  system.  However  by 
completing  the  design  with  external  software  and  having  that  design  built  successfully,  it  demonstrated 
ftiat  the  foundry  was  able  to  accept  designs  from  external  sources.  To  our  knowledge,  the  TDV  was  the 
first  thin  film  module  ever  designed  with  the  software.  By  the  time  the  carrier  was  designed,  the  foundry 
frJo  S)1110"  6XpenenCe  mtb  Cadence  software,  and  that  design  was  completed  very  quickly  (lessthan 

Finally,  another  benchmark  for  the  foundry  was  that  the  TDV  was  the  first  thin  film  vehicle  built  for  an 
external  customer  using  the  International  Standards  Organization  (ISO)  9001  procedures  Also  the 

havmgISO^rtm^on10nS  Standards  being  ProPosed  by  RELTECH  can  be  very  nearly  met  by 

Electrical  testing  of  the  TDV  was  done  in  two  stages.  The  first  stage  consisted  of  opens  and  shorts  testing 
and  occurred  pnor  to  dicing  of  the  four-up  laminate  into  individual  substrates.  The  tests  involved 
checkmg  over  1000  nets  per  substrate  (4000/laminate).  The  second  stage  was  done  after  full  module 

d^  LW3S  TE  •  7“  Stag!  C°DSiSted  0f  a  contmuity  check> or  a  four-point  resistivity  check 
dependmg  on  which  curcuit/net  was  being  tested.  The  test  file  for  the  assembled  modules  contained  117 

points.  The  validity  of  the  interconnection  process  was  gained  by  noting  that  the  electrical 
charactenzation  immediately  after  assembly  was  very  consistent  from  module  to  module,  and  that  very 
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fewpreviously  unknown  defects  occurred.  The  average  number  of  opens  occurring  per  module  vs  the  test 
conditions  is  shown  in  Table  4-2. 

In  Table  4-2,  Pre-conditioning  incorporates  the  following: 

Temperature  shock  ( -40  to  65  °  C,  transition  time  less  than  15  sec);  1  shock  cycle  per  hour-  5 
cycles.  ’ 

*  Random  vibration  ( acceleration  amplitude  approx.  1.8  G  RMS;  30  min  /axis) 

*  Vibration  sweep  (5-500-5  Hz  at  0.44  octave/min;  0.3  G  acceleration;  0.5  mm  displacement- 
1  hr/axis) 

*  Impact  shock  (  X  and  Z  axes;  50  G;  5  msec;  3  repetitions). 

ITie  high  temperature  aging  is  done  at  150°  C  for  500  hours.  The  thermal  cycle  treatments  are  from  0- 

,  .  3 cycles  Per  hour  816  done-  The  temperature  and  humidity  (T/H)  stress  is  done  at  85 0  C  and 
85%  relative  humidity. 


Test  Condition 

Sample  Size 

Average  Number  of  Interconnections  Opens 

As  Assembled 

25 

0.24  (1  module  with  5  unexplained  opens) 

High  Temperature  Aging 

4 

0.25 

Pre  conditioning 

5 

1.2 

100  Thermal  Cycles 
(w/preconditioning) 

2 

0 

500  Thermal  Cycles 
(w/preconditioning) 

2 

0 

1350  Thermal  Cycles 
(w/preconditioning) 

3 

0 

300  hours  T/H 
(w/preconditioning) 

TflhlA  A  XfA  Dnann  _ 

6 

_ xr  1  1  f 

0.3  (1  TAB  net,  1  WB  net  open) 

- — - — — - - - 

Table  4-2:  Avg.  Opens  Occurring  per  Module  vs.  Test  Conditions 


The  only  significant  changes  occurred  during  pre-conditiong.  Most  likely,  the  resulting  opens  occurred  at 
the  Au  perimeter  bonds.  During  that  phase  of  fabrication  some  inconsistencies  in  the  wire  bonding  tool 
were  observed,  and  a  variation  in  pull  strength  was  obtained.  After  the  inconsistencies  were  corrected, 
higher  mid  more  consistent  pull  strengths  were  obtained.  Inspection  of  the  TAB  and  wire  bond  dice  after 
pre-conditionmg  supports  this  conclusion  since  no  wire/lead  breaks  or  peels  were  evident.  The  opens  that 
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4.2  PHYSICAL  TESTING 

4.2.1  Physical  Testing  -Methods 

Destructive  physical  testing  consisted  of  the  following: 

1.  C4  die  tensile  pull.  A  stud  is  adhesively  bonded  to  the  back  side  of  the  die  using  a 
commonly  available  cyanoacrylate  adhesive.  The  stud  is  grooved  so  that  it  can  be  clamped 
by  a  special  fixture  that  inserts  into  the  upper  crosshead  of  an  Instron  tensile  testing 
machine.  The  substrate  is  held  fast  by  a  clamp  on  the  lower  (fixed)  crosshead.  Once  the 
substrate  is  mounted,  the  test  is  conducted  at  a  strain  rate  of  5  mm/min.  at  room  tempera¬ 
ture.  The  force  and  failure  mode  are  recorded. 

2.  Wire  bond  loop  tensile  pull:  The  substrate  is  mounted  on  an  X-Y  translation  stage.  The 
hook  used  to  pull  the  wires  is  connected  a  transducer  that  measures  the  force  (load  cell). 
The  hook  is  lowered  to  a  position  just  above  the  substrate.  The  stage  is  moved  until  the 
wire  to  be  pulled  is  directly  above  the  hook.  The  wire  is  pulled  at  a  strain  rate  less  than 
50  mm/min  at  room  temperature.  The  force  (up  to  a  maximum  of  20  grams)  and  failure 
mode  are  recorded.  Both  the  Al/Si  wedge  and  Au  Ball  bonds  are  tested  using  this  method. 

3.  TAB  outer  lead  tensile  pull:  This  procedure  is  identical  to  the  wire  bond  loop  tensile  pull. 
However,  both  the  inner  and  outer  "keeper"  bars  (strips  of  polyimide  that  hold  the  leads  in 
place  for  bonding)  must  be  removed  prior  to  the  test. 

4.2.2  Physical  Testing  -  Results 

A  summary  of  the  physical  test  results  is  given  in  Table  4-3: 


Condition/Test 

Wirebond  loop 
AlSi  (grams) 

Wirebond  loop 
Au  (grams) 

TAB  OLB  peel 
(grams) 

C4  Dull  tensile 
flbs) 

As-assembled 

7.2 

7.1 

>20 

198 

Ambient  Age,  150° 

C  500  hours 

5.4 

9.8 

>20 

210 

Pre-conditioning 

7.3 

9.0 

>20 

199 

100  Thermal  cycles 
(with  pre-condition) 

7.4 

9.4 

>20 

203 

500  Thermal  cycles 
(with  pre-condition) 

8.2 

10.0 

>20* 

215 

1350  Thermal  cycles 
(with  pre-condition) 

8.3 

9.9 

>20 

199 

300  hrs  temp/hum 
(with  pre-condition) 

ToKIa  A  2.  T>I _ •  T. 

7.5 

—A  _ I J 

9.6 

>20 

215 

Table  4-3:  Physical  Test  Results  as  a  Function  of  Stress 
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To  place  the  data  in  perspective,  the  Military  Specifications  (883)  for  wire  bond  loop  pull  strengths  are 

'  >  oTL3'0?™5  A^Sl  and  Au  wires>  respectively.  The  IBM  specification  for  the  C4  die  tensile  pull 
“  12°  "?s-No  ppeetfichhott  exists  for  the  TAB  outer  lead  bond  ptdl  strength,  so  we  adopted  an  ad-ha; 
nandard  of  16  grans  mnumutn  (Note:  if  treated  like  a  wire,  the  mihttuy  specification  would  be  8  grams), 
e  asterisk  (  )  at  500  thermal  cycles  represents  the  observance  of  an  anomalously  low  TAB  OLB  pull 
strength  (16.5  grams)on  one  specimen.  On  this  particular  die,  it  was  nearly  impossible  to  remove  the 
outer  keeper  bar  without  distorting  the  leads.  This  may  have  affected  the  results. 

The  decrease  in  Al/Si  wire  bond  strength  after  high  temperature  was  expected,  as  was  the  increase  in  Au 
wire  bond  strength.  These  were  simply  due  to  the  aging  characteristics  of  the  two  types  of  wire.  No 
unusual  failure  modes  were  observed.  The  Al/Si  wires  failed  within  the  wire  at  either  bond  site.  The  Au 
wires,  after  aging  failed  within  the  wire  predominantly  at  the  site  at  which  the  tensile  force  was  applied 
Before  aging  the  Au  wire  failures  were  near  the  bond  sites 


The  TAB  OLB  peel  strengths  remained  constant  throughout  the  environmental  exposure  with  the 
exception  noted  above  at  500  thermal  cycles.  This  signifies  that  the  laser  sonic  process  used  was  quite 


The  mtialC4  pull  strengths  were  maintained  throughout  the  pre-conditioning  and  the  T/H  stressing  which 
signified  that  the  packages  remained  heimetically  sealed.  This  is  verified  by  the  electrical  test  results. 
Additionally,  no  C4  electrical  failures  were  observed  with  accelerated  thermal  cycling  up  to  1350  cycles. 
This  is  a  noteworthy  result  that  is  better  than  our  initial  expectations.  We  expected  to  observe  failures  at 
several  hundred  cycles  due  to  fatigue  cracking  that  arises  from  the  cyclic  stress  applied  to  the  solder  joints. 
This  stress  results  from  a  difference  m  thermal  expansion  coefficients  between  the  ceramic  base  (which 
constrains  the  polyimide  motion)  and  the  die  itself.  The  solder  connections  at  the  comers  of  the  die 
experience  the  most  strain,  and  are  prone  to  early  failure.  Under  our  test  conditions,  a  "front"  of  cracked 
C4s  would  move  toward  the  middle  of  the  die  as  cycling  continued.  This  behavior  has  been  well 
characterized  in  the  past  for  ceramic  only  modules  through  modelling.  It  has  also  been  modelled  for 
substrates  that  have  relatively  thin  polyimide  layers  (e.g.  15  microns).  We  observed  evidence  of  C4 
cracking  only  after  1350  thermal  cycles.  It  occurred  at  distances  from  the  neutral  point  (DNP)  greater 
than  approximately  6  mm  (the  maximum  DNP  is  8.8  mm).  As  expected,  the  maximum  cracking  occurred 
at  the  comers  of  the  die,  however,  it  was  confined  to  less  than  20  percent  of  the  contact  area.  This  degree 
of  cracking  is  not  sufficient  to  cause  a  measurable  change  in  the  net  resistance  in  the  TDV. 

The  TDV  has  two  features  that  make  it  different  from  past  products,  which  are  the  polyimide  thickness 
and  the  contact  metallurgy.  These  two  features  may  explain  how  the  C4  results  vary  from  the  existing 
models.  The  thick  polyimide  may  absorb  some  of  the  stress  that  is  induced  during  thermal  cycling  and 
emtermetalhc  layer  formed  during  solder  reflow  may  have  different  mechanical  properties  from  the 
traditional  metallurgy  (see  Figure  4-4).  Most  likely,  the  polyimide  thickness  is  the  dominant  factor. 

vestigation  of  these  possibilities  is  beyond  the  scope  of  this  project.  However,  the  results  have 
generated  an  interest  within  the  East  Fishkill  foundry'  and  most  likely  a  further  study  will  occur. 
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4.3  COST  REDUCTION  RESULTS 

4.3.1  Cost  Reduction  -Methods 

Direct  cost  reduction  practices  involved  the  implementation  of  a  single  top  surface  metallurgy  that  is 

9*’  w*re  ^on<^  TAB  interconnections.  Also,  several  changes  were  incorporated  in 
the  TDV  processing  that  will  reduce  NRE  for  subsequent  thin  film  substrate  builds.  These  are  described 
at  the  end  of  this  section. 

Interconnections  that  use  solder  have  different  requirements  from  those  that  use  thermosonic  or  ultrasonic 
bonding.  The  main  difference  is  that  the  solder  must  interact  with  the  Ni  and  Cu  in  the  contact  metals 
whereas  the  wire  should  be  isolated  from  the  contact  metals.  The  traditional  approach  to  achieve  this  on  a 
single  module  is  shown  in  Figure  4-4  (A).  It  is  a  "dual  gold"  structure,  which  requires  extra  lithography 

and  deposition  steps  to  achieve.  In  our  approach,  a  single  gold  contact  layer  is  desired  as  in 

Figure  4-4  (B).  The  principle  behind  using  a  NiCo  alloy  (instead  of  Ni)  is  that  it  allows  the  solder  to 
interact  with  Cu,  and  prevents  out-diffusion  that  may  render  the  Au  unbondable  to  wire.  The  advantages 
of  the  single  gold  layer  approach  are  that  it  allows  one  metallurgy  to  be  compatible  with  C4,  wire  bond, 
and  TAB  interconnections.  Also,  it  eliminates  an  extra  lithography  step  from  the  process.  The  cost 
benefits  of  such  a  structure  are  shown  in  Table  4-4. 


COST 

SAVINGS/MODTTTF. 

PLATED 

EVAPORATED 

Raw  Machine  Time 

6.3  % 

2.1  % 

Materials,  direct 

$30 

NRE  (mask  savings) 

1 

1 

I  able  4-4:  Cost  Savings  for  Single  Gold  Contact  Layer  “  - - 

i — - - - - - - _ 

CURRENT 

ARPA 

C4,  TAB(solder) 

W/BTAB 

C4,  W/B,  TAB 

1 - - (A) _ _ _  (B) 

Figure  4-4:  TSM  Strategies 
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To  determine  the  feasibility  of  such  an  approach,  we  requested  help  from  the  IBM  Research  Division. 
They  built  a  series  of  "surrogate"  structures  that  could  be  tested.  This  allowed  a  pilot  study  to  be 
completed  without  disrupting  normal  processing  in  the  foundry.  The  surrogates  consisted  of  either  82mm 
Si  wafers  or  127mm  glass-ceramic  substrates,  onto  which  a  9  /urn  polyimide  film  was  deposited. 
Subsequently,  the  contact  structures  were  deposited  via  evaporation  (the  process  used  in  the  foundry  for 
contact  metallization)  through  a  metal  mask  in  a  pattern  onto  which  C4  test  die  could  be  attached,  and 
wire  bonding  practiced.  Various  substrates  had  various  Au  thicknesses. 

Upon  receipt  of  the  surrogates,  a  wire  bond  exercise  was  done.  First,  60  stitch  bonds  of  AlSi  (1%)  wire 
were  made  and  pulled.  The  pull  strengths  and  failure  locations  were  noted.  Then,  30  C4  test  chips  were 
joined,  and  new  wire  bonds  were  made  after  the  reflow.  The  wire  bond  pull  tests  were  then  repeated. 
Additionally,  10  of  the  C4  chips  were  pulled  and  the  strengths  and  failure  modes  noted.  Wire  bonding  and 
chip  pull  exercises  were  conducted  as  joined  (C4),  and  after  3, 6  and  1 1  reflows. 

From  the  above  testing,  the  appropriate  Au  thickness  was  determined  and  a  pilot  run  was  made  in  the 
foundiy.  After  completing  the  analysis  of  the  foundiy  deposited  layer  and  a  short  wire  bond  exercise,  we 
considered  that  the  process  was  transferred  and  it  was  used  on  the  TDV. 

As  mentioned  earlier,  there  were  several  accomplishments  made  in  the  design  and  processing  of  the  TDV 
that  will  contribute  to  cost  reduction  for  subsequent  vehicle  builds.  Among  these  are: 

1.  Development  of  a  standard  alignment  scheme  and  fixturing. 

2.  Increasing  the  allowable  active  area  on  the  substrate. 

3.  Reducing  the  cycle  time  for  polyimide  cure. 

Results  of  these  measures  are  described  in  the  following  'Cost  Reduction  Results'  Section. 


4.3.2  Cost  Reduction  -  Results 
4 .3.2.1  Top  Surface  Metallurgy 

The  dual  thickness  Au  structure  was  designed  to  meet  IBM  specifications  and  requirements.  In  particular, 
hwas  felt  that  any  module  incorporating  mixed  interconnections  would  require  at  most  3  solder  reflows. 
Thus,  our  strategy  was  to  determine  the  contact  structure  that  would  meet  such  a  requirement  with  a  2X 
margin  of  safety  (i.e.,  6  reflows).  The  requirements  for  most  external  customers  however  would  be  less 
m  terms  of  process  reflows. 

The  top  surface  metallurgy  (TSM)  was  described  in  Section  4.3.1  (see  Figure  4-4 )  The  final  Au 
thickness  was  reached  by  examining  the  data  in  Tables  4-5  and  4-6,  which  represent  wirebond  and  C4 
pull  strength,  respectively.  In  Tables  4-5  and  4-6  the  sample  codes  are  as  follows: 

C127A,  F127A,  F127B:  Surrogate  fabricated  in  Yorktown,  127  mm  square  substrate. 

♦  S082A,  S082B:  Surrogate  fabricated  in  Yorktown,  82mm  wafer. 

♦  T127A:  Surrogate  fabricated  in  East  Fishkill  thin  film  foundry,  127  mm  square  substrate. 

♦  W02 12601:  Actual  mechanically  good  TDV 

Table  4-5  represents  wire  bond  loop  pull  strength  (grams)  for  0.00125"  AlSi  (1%)  wire,  wedge-bonded, 
as  a  functron  of  the  number  of  solder  reflows.  The  values  represent  the  mean  of  at  least  50  pulls.  Au  ball 
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bonding  is  also  done  on  certain  specimens.  Table  4-6  represents  C4  pull  strengths  (lbs.)  as  a  function  of 
the  number  of  solder  reflows.  The  values  represent  the  mean  of  5-10  chip  pulls. 


SUBSTRATF. 

PULL  STRENGTH  /  PROCESSING  CONDITIONS 

Code 

Au  Thick 
(nm) 

As-dep. 

IX  reflow 

3X  reflow 

6X  reflow 

11X  reflow 

C127A 

100 

>7.5* 

8.2 

9.3 

9.1 

F127A 

80 

7.3 

9.5 

9.5 

8.0# 

... 

F127B 

220 

9.3 

10.2 

9.1 

11.7 

9.2 

S082A 

80 

10.1 

— 

_ _ 

... 

S082A 

Auwire  .001" 

80 

7.9 

— 

— 

— 

— 

S082B 

220 

11.9 

_ _ 

S082B 

Auwire  .001" 

220 

8.4 

— 

— 

— 

— 

T127A 

150 

9.0 

9.3 

___ 

T127A 

Auwire  .001" 

150 

8.4 

8.6 

— 

— 

— 

W0212601 

150 

11.5 

10.7 

10.5 

W0212601 

Au  wire  .001" 

Tnhl<>4-^-  W;™  VI 

150 

9.6 

1  CX _ ^Ll 

9.6 

■fc.  r  «  ^ 

— 

— 

of  4  rid  ?  off  Iff  ft  Pdl  Strength$  substantially  exceed  Military  Specifications 

of  4.0g  and  3.0g  for  AlSi  and  Au  wire  respectively.  The  standard  deviation  is  approximately  lg  for  all 

!ctp  wf  f  f.'i  5a  nOTDmal  Strengths  "*  h«ha‘ on  the  S082  series  due  to  larger  pad  sizls.  The 
.  f  or  J  rePresents  311  anomalously  low  value  due  to  variations  in  the  wire  bonding  tool 
used  for  the  study.  The  tool  was  serviced  soon  thereafter  and  the  problem  was  corrected.  For  F127A  the 
^cates  ^  3  significant  fraction  of  peel  failures  occurred  with  an  average  strength  of 
6  .  (tbe  ”0nnaI  failuf  mode  18  a  break  “  *e  wire  at  the  "heel"  of  the  bond).  For  these  samples  the 
spf  ftkatior^ standard  deviations  was  at  or  below  the  minimum  strength  required  by  the  military’ 
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SUBSTRATE 

PULL  STRENGTH  /  CONDITIONS 

Code 

Au  Thick, 
(nm) 

As-ioined 

3X 

6X 

ux 

Tcvc. 

Impact 

C127A 

100 

22.0 

22.2 

21.0 

— 

... 

21.6 

C127B 

100 

23.0 

— 

— 

— 

23.0 

F127A 

80 

25.4 

27.5 

24.5 

24.5 

F127B 

220 

27.0 

21.9 

21.6* 

17.6* 

— 

20.3* 

S082A 

Tahlo  A.H- 

80 

rd  Pi.ii 

U _  XT _ a _ 

C  TV  A 

(Strength  exceeds  that  of  wafer ) - 

Tie  C4  data  (Table  4-6)  shows  that  all  values  exceed  the  IBM  specifications  for  the  chip  size  and  C4 
count  used  However,  for  the  values  denoted  with  the  asterisk,  significant  levels  of  contact  metallurgy 
at  ure  at  thechip  were  observed.  Also,  defects  such  as  voids  and  de-wetting  in/of  solder  were  observed  in 
”  denoted  s™Jlef '  ^  Mgh  pull  strength  value,  those  specimens  do  not  meet  the  IBM 

From  Tables  4-5  and  4-6,  a  clear  dichotomy  can  be  seen.  Thick  Au  layers  result  in  good  wire  bond 

7  P°°r  C4Performance  though  multiple  reflow  cycles.  Conversely,  thin  Au  layers  result 

m  good  C4perfomiance  but  poor  wire  bond  perfoimance  through  multiple  reflow  cycles.  Thus  an 

“t6™eJate  fl“cfal?ss  would  represent  the  best  compromise  between  the  two.  The  result  is  that  150  nm 
Au  thickness  was  chosen  for  use  on  the  TDV.  Both  C4  and  wire  bond  joining  to  this  contact  stmcture 
were  successful.  In  30  modules,  two  reflows  were  done  before  any  wire  bonding  was  attempted  No 

0mbtl7n  T  ated  t0  Ttact  “etaIlurgy  were  observed.  In  fact,  some  of  the  highest  Au  ball  bond  strengths 
(up  to  10.5  g  average)  were  obtained  on  finished  TDV  substrates  after  at  least  one  reflow. 

In  Table  4-4,  the  cost  benefits  of  using  this  TSM  structure  were  shown.  The  foundry  delivered  102 

costs  wS«24606  7^77^  T?M  °fvfhich  82  were  electncally  good.  Thus,  the  cost  savings  in  direct 

swiar "  ™ - 


4.3.2.2  Miscellaneous  Cost  Reduction 

Pnor  to  manufacture  of  the  TDV,  no  external  product  had  ever  been  built  as  a  multi-up  (i  e  step  and 

°7 laminate)-  ^  TDV  W3S  built  38  a  four  UP  311(1  h3d  3  larger  active  area 
than  the  standard  internal  product.  It  had  an  active  area  of  1 19.2mm  square  on  a  127.5mm  laminate 

to-teST  T  "er,at,OTP;ed  S““d  an  active  area  of  1 14mm  square. 

As  result  the  standard  practice  of  placmg  the  alignment  fiducials  in  a  symmetric  pattern  in  the  outer 

comers  of  the  laminates  had  to  be  changed.  The  fiducials  on  the  TDV  were  placed  slightly  offset  from  the 

and  Y  centerlines  alternating  between  the  2  locations  on  adjacent  layers.  As  a  result  marks  on  eveiy 

other  layer  were  stacked.  In  order  to  achieve  this,  special  frames  were  constructed  to  protect  the  mar  J 
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during  metal  deposition.  In  practice,  the  laminate  was  rotated  90  degrees  for  each  metal  layer  deposition 

thereby  producing  the  stacked  fiducials.  p 


This  alignment  scheme  was  successful  and  no  adverse  effects  in  pattern  overlay  were  observed  It  has 
become  standardized  and  can  be  used  on  future  OEM  product  built  in  the  high  volume  foundry.  The  cost 
savings  associated  with  this  is  completely  in  non-recurring  engineering  (NRE)  and  is  significant.  In  the 
past,  an  alignment  scheme  would  be  devised  for  each  product.  This  would  take  one  man-day  of  design 
time  one  man-day  for  a  design  review,  and  some  process/tool  time  for  verification.  Additionally  a  new 
set  of  protective  fixtures  for  metal  deposition  would  be  required  for  each  design.  These  fixtures  have 
strict  requirements  for  flatness  and  shape  that  increase  the  cost  to  approximately  $400  each  Typically  1 6 
are  used  m  production  for  volumes  similar  to  the  TDV.  Thus,  the  total  cost  savings  is  $6400  plus  two  ’ 
man-days  of  fully  burdened  design  labor. 


The  very  large  active  area  of  the  TDV  resulted  in  some  processing  challenges  to  overcome,  which  were 
due  Primarily  to  the  buildup  of  polyimide  at  the  edge  of  the  laminate.  Some  operations  that  would 
normally  be  done  automatically  had  to  be  done  manually.  In  general,  the  yield  decreases  as  the  number  of 
manual  steps  increases.  The  TDV  was  no  exception,  although  most  of  the  defects  resulting  in  yield  loss 
were  confined  to  a  small  band  approximately  0.6mm  wide  at  the  edge  of  the  active  area.  Based  on  this 
experience  it  was  felt  that  the  largest  active  area  that  could  be  processed  with  high  yield  is  1 1 8mm.  This 
has  been  adopted  as  a  groundrule  in  the  foundiy.  Using  this  active  area  groundrule,  many  of  the  manual 
operations  can  be  converted  back  to  automatic,  resulting  in  reduced  turn  around  time  and  cost  An 
additional  benefit  is  that  the  maximum  size  for  multi-up  substrates  is  increased  to  59  1mm  for  4-up 
38.9mm  for  9-up,  and  28.9mm  for  16-up. 


One  other  process  modification  designed  to  reduce  cost  and  cycle  time  that  was  incoiporated  was  a 
reduced  cure  cycle  for  the  polyimide  (PI)  cure.  The  standard  cycle  runs  approximately  13  hours  and  is  a 
stepwise  cure  to  400  "C.  The  new  cycle  has  a  continuous  ramp  to  400 0  C,  and  takes  approximately  3.5 
tiTfl  °r  ®JDV,  this  represented  approximately  a  3%  savings  on  raw  process  time.  It  is  expected 
that  future  products  will  benefit  from  this  much  more  than  the  TDV  as  there  was  significant  rework 
associated  with  the  TDV  due  to  the  developmental  nature  of  the  vehicle. 
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4.4  CONCLUSIONS 


In  almost  every  sense,  the  TDV  was  a  development  vehicle  that  pushed  the  East  Fishkill  foundry  to  new 
limits.  From  design  through  die  attach,  new  processes  were  attempted. 

Design:  Because  die  TDV  was  the  first  thin  film  vehicle  designed  with  Cadence  Allegro-E  software 
knowledge  was  gained  that  was  useful  in  formulating  the  design  kits.  For  example,  it  became  clear  that 
automatic  mesh  generation,  redistribution,  and  mesh  cutout  routines  would  be  necessary  to  reduce  the 
design  time  substantially.  All  of  these  have  been  written  and  incorporated  into  the  design  kits. 
Additionally,  routing  strategies  have  been  optimized  based  on  the  TDV,  and  the  appropriate  parameters 
have  been  incorporated  into  template  board  files  provided  with  the  kits. 

Processing:  The  TDV  build  brought  about  innovations  in  processing  that  resulted  in  cost  reductions  as 
described  m  detail  above.  Additionally,  the  timing  of  the  build  was  such  that  plate-up  processing  was 
brought  into  the  high  volume  foundry  ahead  of  schedule.  The  learning  gained  by  that  accomplishment  has 
been  applied  to  new  products  that  have  been  processed  there  with  high  yield.  Also,  the  TDV  build  has 
resulted  in  an  increase  m  the  allowable  active  area  on  the  foundry's  standard  form  factor.  This  results  in 
savings  to  customers  because  a  greater  number  of  substrates  can  be  processed  per  laminate. 

urun”6^0111  The  results  described  above  show  clearly  that  mixed  interconnection  is  feasible  on 
MLM-D  products.  The  experience  gained  by  building  the  vehicle  has  been  useful  in  setting  design 
groundrules  for  both  wire  bond  and  TAB  contact  pads.  The  TAB  OLB  had  the  finest  pitch  of  any  TAB 
device  attached  to  an  IBM  module.  The  fact  that  approximately  100  TAB  dice  could  be  bonded 
automatically  is  ample  proof  that  the  lasersonic  process  is  viable  as  an  interconnection  technique. 

Packaging:  The  flat  carrier  with  a  peaked  Kovar  lid  was  chosen  as  the  lowest  cost  hermetic  solution  to 
packaging  the  TDV.  Although  we  were  able  to  bond  the  TDV  to  the  carrier,  the  long  wire  run  and  bond 
depth  are  impractical  for  most  environments  when  the  substrate  is  greater  than  50mm  square  We  would 
recommend  that  such  an  approach  be  limited  to  substrates  less  than  or  equal  to  44mm  square  An 
informal  survey  reveals  that  modem  wire  bond  tools  exist  with  such  capabilities.  Additionally,  the  smaller 
size  would  extend  the  thermal  cycling  lifetime  of  the  hermetic  seal,  although  we  did  not  observe  anv 
hermeticity  degradation  under  the  test  conditions  used  here. 


AJthough  the  TDV  was  a  development  vehicle  in  almost  every  sense,  it  performed  very  well  under  typical 
Jw  Jf5*  These  teste  were  meant  to  simulate,  in  an  accelerated  fashion,  the  types  of  stresses 

that  the  module  might  undergo  in  a  commercial  or  consumer  environment.  Although  a  full  product 
qualification  was  not  attempted,  the  results  obtained  above  combined  with  the  learning  suggest  that  the 
TDV  could Ibc =  firily  quahfied  to  IBM  standards.  Stressing  of  38  modules  to  Military  Specifications  will 
be  conducted  by  RELTECH.  It  will  be  interesting  to  compare  those  results  with  the  ones  described  here. 
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5.0  INFRASTRUCTURE 

There  are  a  number  of  infrastructure  issues  that  needed  to  be  addressed  in  order  to  improve 
industry  availability  and  acceptance  of  MCMs.  These  included: 

•  Definition  of  standard  substrate  sizes  and  I/O  assignments;  to  increase  reuse  of  design 
data,  manufacturing  and  test  fixtures,  and  to  reduce  NRE  costs  and  cycle  time 

•  Definition  of  foundry  interface  specifications;  to  assist  customers  in  being  able  to  use 
multiple  MCM  foundries 

•  Definition  of  design  kit  standards;  to  assist  foundries  in  defining  their  technology  to  the 
variety  of  commercially  available  design  tools 

•  Definition  of  standards  for  Electronic  Data  Books;  to  improve  transfer  of  component  data 
between  design  tools 

•  Solutions  to  MCM  test  issues  such  as:  chip  sets  with  a  variety  of  testability  features, 
known  good  die,  and  test  file  generation 

•  Solutions  to  address  the  interconnect  technology  issues  such  as;  helping  the  industry 
understand  flip  chip  (IBM  C4)  technology  and  interconnect  reliability 

This  infrastructure  section  describes  activities  that  addressed  the  listed  MCM  concerns  and  worked 
towards  enhancing  MCM  technology  acceptance  in  the  industry.  Four  areas  of  infrastructure  will 
be  described  in  the  following  sections: 

•  Application  Demonstration  (Substrate  Standardization) 

•  CAD  Infrastructure  (Customer-foundry  interface  specifications.  Electronic  Data  Books) 

•  Module  Test  (Testability,  Known  Good  Die,  Test  File  Generation) 

•  Interconnection  Technology  (Flip  Chip,  Interconnect  Reliability) 

Additional  details  can  be  found  in  contract  deliverable  "Report  on  Infrastructure  Plans  and 
Accomplishments,  Final  Report",  0002AQ. 

5.1  Application  Demonstration 

The  major  infrastructure  accomplishment  resulted  from  work  with  ISI,  the  Mayo  Foundation,  and 
internal  applications  team  activity.  Additional,  less  measurable,  results  came  from  industry 
interaction  at  conferences  and  meetings. 

5.1.1  ISI/MOSIS 

The  University  of  Southern  California’s  Information  Sciences  Institute’s  (ISI’s)  charter  was  to 
form  an  MCM  brokerage  service  to  facilitate  foundry  access  for  smaller  customers.  The  model  for 
their  operation  was  the  MOSIS  service  for  application  specific  integrated  circuits,  in  which  several 
different  designs  are  combined  into  a  single  mask  set  that  can  be  run  in  a  single  foundry.  By  doing 
this,  the  non-recurring  engineering  charges  (NRE)  can  be  spread  over  several  customers,  thus 
lowering  the  total  cost  to  each.  In  the  ISI  model,  individual  substrate  designs  would  be  submitted 
and  combined  electronically.  Subsequently,  ISI  would  provide  a  complete  set  of  exposure  masks 
(and  substrate  test  vectors).  A  requirement  for  smooth  operation  and  low  cost  is  to  standardize  the 
designs  as  much  as  possible  (i.e.  substrate  size,  pad  layouts,  etc.). 
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The  ASEM  team  has  worked  closely  with  ISI  to  put  the  model  into  practice.  Initially,  a  complete 
set  of  thin-film  technology  ground  rules  was  provided  to  ISI  so  that  they  could  gain  familiarity  with 
the  E.Fishkill  foundry  capabilities.  A  set  of  proposed  standard  sizes  was  also  provided.  In  feet, 
the  resulting  ISI  standard  sizes  (i.e.,  25,  37,  47  and  57  mm  square)  were  very  close  to  those 
proposed  by  IBM.  Following  this  initial  activity,  ISI  toured  the  foundry  and  met  with  us  to 
determine  the  best  processing  scheme  to  use  in  our  factory.  It  was  decided  that  a  full  field 
approach  (as  opposed  to  step  and  repeat)  offered  the  maximum  benefit  in  terms  of  low  cost.  Thus, 
a  full  set  of  (metal  expose)  mask  specifications  and  the  necessary  alignment  fiducials  (in  electronic 
form)  were  provided.  IBM  was  the  only  supplier  chosen  by  ISI  that  formed  vias  by  laser  ablation. 
Because  the  laser  mask  process  is  proprietary,  specifications  could  not  be  provided.  However,  it 
was  decided  that  alignment  fiducials  (and  locations)  could  be  provided,  thereby  allowing  ISI  to 
produce  electronic  versions  of  laser  masks,  which  could  then  be  built  by  IBM.  ISI  was  supplied 
IBM  MCM-D  design  kits  for  the  Cadence  and  Mentor  Graphics  design  tools.  In  addition,  special 
data  formats  to  support  the  uniqueness  of  the  ISI/IBM  relationship  were  developed  for  substrate 
opens/shorts  test  data.  While  ISI  was  preparing  two  37  mm  designs  for  a  qualification  run,  a  “test 
mask”  was  generated  and  shipped  to  IBM.  This  was  used  to  build  a  single  metal  layer  on  a  127 
mm  substrate.  The  resulting  metal  pattern  was  measured,  and  alignment  of  the  substrate  on  other 
foundry  tools  was  attempted  (with  success).  Once  this  process  was  verified,  ISI  was  given 
instructions  to  proceed  with  a  complete  mask  set. 

Initial  parts  are  to  be  delivered  in  December  1994  and  ongoing  regularly  scheduled  builds  are 
planned. 

5.1.2  Mayo  Foundation,  Special  Purpose  Processor  Development.  Group 

Another  of  the  activities,  which  was  part  of  the  infrastructure  task,  was  the  involvement  with  the 
Mayo  Foundation’s  Special  Purpose  Processor  Development  Group.  Mayo  is  one  of  the  other 
ARPA  ASEM  Contractors.  Their  goals  for  the  ASEM  Program  is  to  take  the  currently  available 
MCM  technologies  and  determine/demonstrate  the  maximum  rates  of  operation. 

The  infrastructure  activity  that  occurred  during  this  ASEM  contract  focused  on  passive  designs  for 
both  MCM-C  and  MCM-D  substrates.  The  passive  design  is  the  standard  Mayo  passive  MCM 
design.  It  consists  of  various  line  structures  that  will  be  evaluated  in  terms  of  impedance,  loss, 
crosstalk,  etc.  Mayo  performed  the  design  and  layout  with  the  help  of  the  University  of  Wisconsin 
at  Milwaukee.  The  interface  with  IBM  was  at  the  completed  physical  design  level.  Consultation 
on  the  use  of  the  IBM  Design  Kits,  IBM  Design  Ground  Rules,  and  the  IBM  Manufacturing 
process  was  also  provided.  Mayo  has  plans  to  share  all  their  results  with  IBM  and  the  rest  of  the 
ASEM  community  which  have  supplied  or  will  supply  passive  substrates.  These  vendors  are 
nCHIP,  ISA,  Hughes,  Georgia  Tech,  Texas  Instruments,  Acsist,  Motorola,  and  MicroModule 
Systems. 

The  standard  passive  coupon  which  Mayo  has  been  evaluating  has  specific  lengths  and  spacings, 
simple  basic  structures,  the  same  design  for  all  the  contractors,  and  the  same  set  of  tests  performed 
on  the  completed  modules.  Of  the  ASEM  contractors,  IBM  will  be  the  only  one  to  supply  a  MCM- 
C  vehicle.  IBM  will  also  supply  a  MCM-D  vehicle. 

The  MCM-C  passive  coupons  was  127mm  x  127mm  Alumina  ceramic.  It  was  15  greensheet 
layers  thick  with  top  surface  probe  pads  as  module  I/O.  The  substrate  was  build  using  IBM 
standard  multi-layered  ceramic  manufacturing  process  including  mechanical  punch  for  substrate 
personalization  and  immersion  gold  top  surface  plating.  The  MCM-D  passive  coupons  was  a 
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60mm  x  60mm  multilayer  thin  film  package  on  a  blank  Alumina  ceramic  substrate.  This  five  layer 
thin  film  structure  was  built  using  IBM’s  25p  lines  on  lOOp  center  groundrules. 

Mayo’s  high  speed  testing  methodology  was  identified  for  both  the  active  and  passive  coupons. 
Testing  of  passive  coupons  is  performed  using  a  0-26  GHz  sweeper  in  combination  with  cascade 
probes.  The  preferred  probe  has  it’s  signal  line  bracketed  by  ground  lines.  This  topology  can  be 
seen  in  the  TSM  layout.  The  design  of  the  passive  coupon  explores  signal  power  loss  by  probing  a 
variety  of  line  topologies  including  closely  coupled  and  mitered  comer  lines. 

The  'C'  and  'D'  passives  were  delivered  in  October  1994  and  are  under  test  at  Mayo. 

5.1.3  Hardware  Standards 

The  team  leaders  in  each  of  the  IBM  ASEM  task  groups  have  put  together  a  list  of  MCM  features 
that  should  be  included  in  industry  standards  discussions. 

For  example;  An  application  questionnaire  has  been  generated  based  on  input  from  the  design, 
modeling,  thermal,  encapsulation,  and  test  groups.  The  key  technology  and  business  items  were 
included.  The  questionnaire  has  been  distributed  to  the  foundry  for  comments.  This  questionnaire 
has  become  the  standard  for  the  IBM  foundry  and  will  be  used  in  discussions  with  other  foundries 
about  standardization.  Discussions  with  other  foundries  about  the  questionnaire  has  not  yet 
begun. 

5.1.4  Industry  Conferences  and  Meetings 

In  addition,  team  members  have  participated  in  the  following  conferences  and  ARPA  team 
meetings. 

ARPA  ASEM  conference  -  Phoenix,  Arizona  March  23-24  1993 
IEEE  MCM  conference  -  Santa  Cruz,  California  March  22-25  1993 
GOMAC  ‘93  -  New  Orleans,  LA  November  1-5, 1993 

ARPA  EP&I  Conference.  Marina  Del  Rey,  CA.,  2/94:  Several  Papers;  Presented  by  Y.Ting, 

H. Clearfield,  L.S.Su,  and  N.Volkringer. 

ISHM  ‘94  -  Denver:  Paper  Presented  “50MHZ  MCM-C  Processor  Module  with  Flip  Chip 
Technology”  By  W.Miller,  Y.Ting,  N.Volkringer,  &  L.S.Su. 

ISHM  Advanced  Technology  Workshop,  MCM-D  and  MCM-L,  Invited  Paper  Presented 
“IBM  ASEM  Activity”  By  H.Clearfield  (Ogunquit,  Maine,  June,  1994) 

GOMAC  ‘94  -  San  Diego:  Abstract  Submitted:  “Electrical  Characterization  And  Design  Using 
IBM’s  MCM-C  Packaging  Technology”  By  N.Volkringer  And  W.Jennings. 

5.1.5  Application  Demonstration  Conclusions 

Significant  progress  has  been  made  regarding  hardware  standards  and  industry  awareness  of  IBM's 
technology  characteristics.  Additional  applications  will  benefit  from  this  progress. 

5.2  CAD  Infrastructure 

The  major  accomplishments  have  been  related  to  work  with  the  ASEM  Alliance  toward  Foundry 
Interface  Standards  and  Information  modeling  of  MCM  descriptions.  The  information  modeling 
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activity  couples  closely  with  EDIF-PCB  extensions  that  could  lead  to  better  MCM  electronic  data 
books  (EDBs)  and  Design  Kit  Standards. 

5.2.1  ASEM  Alliance  Results  /  Standards 

ASEM  Alliance  meetings  initially  discussed  possible  areas  for  standardization.  The  primary 
interface  of  interest  was  that  of  the  completed  physical  design  entry  into  the  foundry.  There  were 
many  foundry  unique  requirements  due  to  the  special  processing  capabilities  at  each  of  the 
foundries.  Despite  these  differences,  a  draft  of  an  ASEM  Foundry  Interface  Specification  was 
published.  IBM  chaired  many  of  the  foundry-to-customer  working  group  meetings. 

In  publishing  the  interface  document,  the  core  reasons  for  differences  came  under  discussion.  It 
was  determined  that  the  information  to  describe  the  data,  which  must  be  exchanged  from  MCM 
foundry  to  customer,  had  to  be  studied.  Some  of  the  basis  for  the  information  content  came  from 
MCC  experience  with  DICE  and  the  ROSE  data  base  activity.  With  that  demonstration  base, 
further  discussions  were  held,  which  lead  to  evaluating  the  EDIF-PCB  information  model  relative 
to  the  MCM  requirements.  Discussions  and  meetings  with  the  EDIF-PCB  working  group  lead  to 
current  activity  in  EDIF  of  trying  to  incorporate  ASEM  findings  into  a  follow-on  EDIF-PCB 
releases. 

Progress  towards  an  EDB  standard  and  a  Design  Kit  Specification  has  been  made  with  the  ASEM 
Alliance  activities  relating  to  the  information  modeling  of  MCMs.  Additional  effort  will  be  needed 
to  follow  through  with  this  activity. 

5.2.2  Other  organization  Support 

CFI-CIR  Meetings:  Contributed  to  Proof  of  Concept  EDB  request  for  technology.  Also 
contributed  to  terms  dictionary  and  scenarios  development. 

Logic  Modeling  Corporation:  Hosted  meeting  at  IBM  E.Fishkill  to  review  bare  die 
information  requirements  for  ARPA  chip  library  work.  Module,  Electrical,  and  Test 
requirements  were  discussed.  3/10/93 

Participated  in  many  of  the  review  meetings  for  the  Die  Information  Format  and  provided 
an  IBM  EDB.DTD  (Document  Type  definition)  for  use  in  establishing  SGML  format 
option. 

Continued  recommending  this  format  in  documentation,  papers,  and  industry  discussions. 

Tanner  Research:  GDS2  was  provided  for  a  sample  MCM  along  with  the  design  kit 
specification  and  the  documentation  associated  with  the  Cadence  MCM-D  kit. 

Cooper  Chyan  Technologies:  An  Allegro  .brd  file  of  a  sample  MCM-C  was  provided  to  CCT 
to  allow  tool  evaluation  of  channel  routing  objectives  for  mesh  plane  technologies. 
Technology  discussions  followed.  CCT  currently  doesn’t  have  controls  to  force  signal 
routing  to  align  underneath  mesh  lines.  This  is  considered  important  for  technologies  with 
mesh  planes. 

University  of  Tennessee,  Knoxville:  Hosted  meeting  at  IBM  E.Fishkill  with  Dr.  Don  Bouldin 
with  regard  to  semiconductor  design  using  flip  chip  pad  arrays. 

Cadence,  Mentor  Graphics,  Intergraph,  Harris  EDA,  and  Racal-Redac:  Ongoing  discussions 
regarding  design  kit  development  activity  and  other  CAD  issues. 
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5.2.3  Industry  Conferences  and  Meetings 

Multichip  Module  Conference:  Conference  attended,  March  15-18*  discussions  held  with 
other  attendees/  presenters  on  MCM  infrastructure  topics.  MCM  Design  kit  plans 
discussed  with  attendees  at  the  IBM  Technology  booth. 

MCM  design  kit  demonstrations  on  both  the  Mentor  Graphics  and  Cadence  design  tools 
were  shown  at  the  Feb.,  94  conference. 

IPC  Fall  meeting:  Paper  presented  entitled  “The  MCM-L/SCM-L  Design  Infrastructure: 
Matching  Customers  to  Foundries”  at  in  October  1993  in  Alexandria,  VA. 

ISHM  Conference:  Conference  attended,  April  13-16*  discussions  held  with  other 
foundries/EDA  suppliers  on  Design  Kit  support  and  standardization. 

MCM  design  kit  demonstrations  on  both  the  Mentor  Graphics  and  Cadence  design  tools 
were  shown  at  the  April  94  conference. 

Workshop  on  Enabling  Technologies  U  of  W.  Virginia:  Attended  CERC  meeting  and 
collaborated  on  a  short  paper  on  collocation  (multi-location  concurrent  engineering 
activity) 

ARPA  Contractors  Conference:  Conference  attended,  Feb.  94,  MCM-D  kits  demonstrated  for 
the  first  time  on  both  the  Mentor  Graphics  and  Cadence  tools  running  concurrently  on  an 
RS6000. 

PCB  Design  Conference:  Mini-Course  presented  on  “MCM  Technology:  Design  For 
Optimized  Application”  March  28-31,  1994,  Santa  Clara,  CA  (1) 

5.2.4  CAD  Infrastructure  Conclusions 

Relationships  have  developed  between  IBM  and  other  MCM  companies,  consortia,  and  standards 
organizations.  This  has  created  contacts  for  discussions  of  MCM  description  requirements,  MCM 
design  kit  requirements,  and  customer/foundry  interfaces.  The  ASEM  Alliance  has  been  an 
effective  forum  for  improving  the  consistency  of  foundry  interfaces. 

The  CIR  and  Conference  attendance  has  influenced  approaches  to  design  kit  specifications, 
content,  and  future  directions  as  electronic  design  representation  and  exchange  concepts  are 
discussed  in  die  open  forum.  Instead  of  working  individually  with  the  CFI/CIR  organization,  our 
proposals  and  efforts  for  standardization  moved  to  activities  within  the  ASEM  alliance.  We 
worked  towards  MCM  (EDB)  standards  and  design  kit  standards  through  work  with  the  ASEM 
Alliance  which  included  reviewing  the  information  model  of  EDIF  PCB  for  possible  extensions  to 
cover  MCMs. 

We  contributed  to  other  industry  activities  by  providing  IBM  perspectives  on  the  DIE  Format 
being  created  by  Synopsis  (Logic  Modeling  corporation)  and  work  being  done  by  Dr.  Bouldin’s 
University  of  Tennessee  activity. 

Information  has  been  shared  and  discussions  have  been  held  with  Tanner  Research  and  Cooper 
Chyan  Technologies,  as  well  as  Cadence,  Mentor  Graphics,  Intergraph,  Harris  EDA,  and  Racal 
Redac. 
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5.3  Module  Test  /  Known  Good  Die 


The  major  accomplishments  have  been  in  the  sharing  of  experience  and  recommendations  in  the 
areas  of  MCM  Test  and  Known  Good  Die  (KGD). 

5.3.1  MCM  Test 

Paper  presented  titled  "The  Test  Challenges  for  an  ASEM  Foundry"  by  T.  Story,  E.  Atwood, 

C.  Lapihuska  and  L.  Su,at  the  27th  International  Symposium  on  Microelectronics 
sponsored  by  the  International  Society  for  Hybrid  Microelectronics,  Boston,  MA.  Nov.  15- 
17, 1994. 

Paper  presented  titled  "A  Test  Methodology  to  Support  An  ASEM  MCM  Foundry"  by  T. 
Story,  E.  Atwood,  C.  Lapihuska  and  L.  Su,at  the  IEEE  International  Test  Conf., 
Washington,  D.C.,Oct.  3-5,  1994. 

Paper  presented  titled  "Data  Integrity  Concerns  for  Multichip  Module  Testing",  by  L.  Su  and 
E.  Atwood,  at  the  International  Electronic  Packaging  Society  Conf.,  Atlanta,  GA.  Sept. 
25-28,  1994. 

Paper  presented  titled  "MCM  Test  using  Boundary-Scan  Methods  for  Internal  and  Merchant 
Designs"  by  E.Atwood,  at  the  MCM  Test  Workshop,  Napa,  CA.  September  1 1-14,  1994. 

Paper  presented  titled  “1 149. 1  MCM  Interconnect  Testing  Using  Victory  ATPG  and  Scan 
Chain  Serializer”  at  the  Teradyne  Users  Group  Workshop,  4/25-27/94,  Santa  Clara,  Ca. 

Paper  presented  titled  “A  Test  Methodology  and  It’s  Implementation  to  Support  an  ASEM 
Foundry”  by  T.  Story,  E.  Atwood,  C.  Lapihuska  and  L.  Su,at  the  ARPA  EP&I  Meeting, 
2/14-17/94,  Marina  Del  Rey,  Ca. 

Attended  IEEE  MCM  conference,  MCMC-93,  3/15-18/93,  Santa  Cruz,  CA 
Attended  IEEE  BIST/DFT  Workshop,  3/17-19/93,  Charleston,  SC 
Attended  IEEE  VLSI  test  symposium,  4/5-8/93,  Atlantic  City,  NJ 
Attended  Workshop  In  Hierarchical  Test  Generation,  8/9-11/93,  Blacksburg,  Va. 

Attended  FTC  Conference,  10/17-21/93,  Baltimore,  MD 
Attended  IEEE  VLSI  Test  Symposium,  4/26-28/94,  Cherry  Hill,  NJ 

5.3.2  Known  Good  Die 

Active  participation  in  Bumped/Tabbed  Die  Sub-committee  KGD  task  force 

(Guideline  for  Procurement  and  Use  of  Known  Good  Die)  1/20/93,  Austin,  TX;  3/2/93, 
Austin,  TX;  4/13/93,  Denver,  CO;  5/13/93,  Austin,  TX. 

Published  In  MCC’s  “Consortia  For  KGD  Phase-I”  Report  WL-TR-94-5008,  2/94 

Active  participation  in  MCC/SEMATECH/ARPA  project  meeting  on  KGD 

(KGD  Assurance  Technology  Assessment  Guidelines)  1/21/93,  Austin,  IX;  3/3/93, 

Austin,  TX;  4/13/93,  Denver,  CO; 

Published  In  MCC’s  “Consortia  For  KGD  Phase-I”  Report  WL-TR-94-5008,  2/94 

Assembled  a  team  with  members  from  IBM  Packaging  Business  Unit  including  Bond, 
Assembly,  and  Test  personnel  to  assist  MCC  in  formulating  the  ARPA  Phase  II  KGD 
plan. 
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Presented  and  discussed  the  IBM  KGD  strategy  and  experience  with  engineers  from 
RELTECH,  Sun,  and  National  Semiconductor. 

Attended  1993  Advanced  Microelectronics  Qualification/Reliability  workshop,  8/24-26/93 
Denver  CO. 

5.3.3  Other  organization  Support 

Discussed  bare  die  test  information  requirements  with  Logic  Modeling  Corporation  at  meeting 
in  IBM  E.Fishkill.  3/10/93 

Initiated  a  series  of  meetings  with  Mentor  Graphics/Teradyne  and  Cadence  in  an  effort  to 
speed  up  the  development  of  Test  Pattern  Generation  software. 

Continued  testing  the  Victory  ATPG  Software  as  a  beta  site  for  Teradyne.  Surfaced  major 
problems  in  dealing  with  Virtual  Component  Clustering  Test  (VCCT).  Results  shared  with 
Teradyne  and  plans  for  a  solution  discussed.  Updated  Beta  software  is  under  test. 

5.3.4  Module  Test  /  Known  Good  Die  Conclusions 

Attendance  in  test  related  conferences  and  workshops  has  provided  an  important  influence  in  the 
development  of  a  standardized  and  effective  test  methodology.  Broad  industry  interactions  at  such 
forums  is  helping  to  converge  the  scope  and  range  of  OEM  test  methodologies. 

Attendance  in  the  MCC  phase  I  KGD  efforts,  ARPA  sponsored  EP&I  meetings,  and  industry 
forums  such  as  the  ISHM  Conference/exposition  has  provided  a  forum  for  disseminating  IBM 
knowledge  of  KGD  issues  related  to  manufacturing  of  MCM’s  &  Die  Bum-in,  has  provided  a 
forum  to  influence  the  content  of  proposed  KGD  standards,  and  has  influenced  IBM’s  approach 
and  understanding  of  KGD  issues  involving  wire  bond  die. 

5.4  Interconnection  Technology 

Major  accomplishments  have  been  in  leading  industry  activity  and  sharing  interconnection  and 
material  knowledge  and  experience  in  the  following  arenas: 

•  Presenting  results  on  TSM,  thin  film  and  module  assembly  development  at  various  MCM- 
related  conferences 

•  Chairing  sessions  at  conferences  and  workshops 

•  Serving  on  organizing  committees  for  MCM  related  conferences  and  workshops 

•  Participating  in  known  good  die  standardization 

•  Presenting  C4  reliability  experience  to  establish  widespread  knowledge  based  on  flip  chip 
technology  for  MCMs 

•  Providing  physical  specifications  in  support  of  standardization  of  MCM  designs 

•  Reviewing  proposed  standards  and  provide  feedback  to  other  members  of  ASEM  team 
5.4.1  Industry  Conferences  and  Meetings 

M.I.T.  Packaging  Program  Workshop:  Paper  presented  on  ‘Chemistry  and  Long  Term 
Durability  of  Metal  Polyimide  Interfaces:  Processing  and  T/H  Stresses’;  review  panel 
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member  providing  feedback  on  program’s  progress  as  well  as  setting  strategic  directions 
for  the  program.  Jan.  93. 

Review  panel  member  and  participant  in  guiding  the  activities  to  solve  industry  MCM 
processing  problems.  April  93. 

Review  panel  member  as  above,  November  93. 

U.  ARIZ./IEEE/CHMT  Workshop:  Participant  in  benchmarking  industry  use  of  flip  chip  die 
attach  technology  against  IBM  experience;  provided  comments  and  feedback  on  industry 
standard  die  attach  techniques.  Jan.  93. 

CHMT/ISHM  Workshop  Advanced  Materials:  Paper  presented  on  ‘Chemistry  and  Long  Term 
Durability  of  Metal  Polyimide  Interfaces:  Processing  and  T/H  Stresses’;  benchmark 
industry  standard  substrate  technology  against  IBM  experience.  Feb.  93. 

ARPA/SEMI/EIA  MCM  Workshop:  Participant  providing  input  and  comment  on  industry 
standard  tooling  issues  in  MCM  manufacturing.  Feb.  93.  Internal  IBM  meetings  held  to 
set  strategy  for  EIA  participation  and  work  areas  to  be  addressed.  April  93. 

Adhesion  Society  Symposium:  Session  chairman  on  Metal/Polymer  Interfeces;  organizing 
committee  providing  input  for  future  directions  of  the  symposium.  April  93. 

Materials  Research  Society  Spring  Symposium:  Paper  presented  on  ‘Ta/Polyimide  Interface 
Durability:  Correlation  to  Chemistry  and  Water  Uptake’;  session  chaired  on  Interface 
Properties  and  Durability.  April  93. 

IBM  Symposium  on  Reliability  and  Statistics:  Paper  presented  on  ‘Statistics  for  Crack 
Initiation  and  Propagation’.  April  93. 

ISHM  MCM-C  Workshop:  Participant  in  benchmarking  IBM  MCM-C  technology,  design 
capability,  interconnection  and  tum-around-time  against  other  MCM  vendors;  learned 
about  latest  materials  and  processes  for  high  performance  modules.  August  93 

Advanced  Microelectronics  Qualification/Reliability  Workshop:  Presented  a  paper  entitled 
“Interconnection  Fatigue  Modeling,”  Denver,  CO,  August  93 

Gordon  Research  Conference  on  Adhesion  Science:  Chairman  of  conference,  which  included 
presentations  on  low-  cost  metalization  and  reliability.  New  Hampton,  NH  August  93. 

Inti.  Symposium  on  Microelectronics  (ISHM  93) :  Invited  paper  presented,  entitled  “Chemistry 
and  Long-Term  Durability  of  Metal/Polyimide  Interfeces:  Processing  and 
Temperature/Humidity  Stresses.”  Paper  won  a  “Best  of  Session”  award. 

ASEM  TDV  substrates  displayed  at  the  trade  show,  which  generated  interest  in  IBM  thin  films 
technology.  Dallas,  November  93. 

Materials  Research  Society  Fall  Symposium:  Invited  paper  presented,  entitled  “Factors 
Affecting  the  Long-  Term  Durability  of  Metal/Polymer  Interfeces  in  Microelectronics 
Packaging:  Chemistry  and  Water  Uptake.”  November  93 

ARPA  EP&I  Principal  Investigators  Meeting:  Presented  a  Paper  Entitled  ‘Technology  for 
Mixed  Interconnection  on  Thin  Film  Multichip  Modules”  (Marina  Del  Rey,  Ca.,  February, 
1994) 
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International  Conference  on  Multichip  Modules:  Presented  a  paper  entitled  “Implementation  Of 
Advanced,  Micro-Interconnection  Techniques  on  A  Thin  Film  Multichip  Module”;  Session 
Chair  in  “Materials  and  Processes”  (Denver,  April,  1994) 

International  Symposium  On  Microelectronics  (ISHM  ‘94):  Session  Chair,  “MCM 
Packaging”;  paper  presented,  entitled  “A  Single  Contact  Metallurgy  for  Flip  Chip, 
Wirebond,  and  TAB  Applications  on  Thin-Film  MCM’s”  (Boston,  November,  1994) 

International  Society  For  Hybrid  Microelectronics:  H.  Clearfield  Selected  for  the  National 
Technical  Program  Committee,  The  Subcommittee  on  Packaging 

The  Adhesion  Society  :  H.  Clearfield  elected  vice-president  (president-elect) 

5.4.2  Other  organization  Support 

RELTECH:  Meetings  2/4,  2/26  and  3/1 1  discussing  common  test  vehicles  and  reliability 
experiences 

IBM  ASEM  TDV  test  plan  presented  at  RELTECH  Symposium  4/13/93. 

IBM  ASEM  TDV  test  plan  approved  by  RELTECH  4/13/93.  Hosted  a  visit  to  IBM  E. 
Fishkill  by  RELTECH  as  part  of  their  survey  of  all  ASEM  contractors.  Provided 
information  on  the  TDV  processing  and  test  objectives.  July  93. 

Attended  RELTECH  Committee  Meeting,  Denver,  CO,  August  93  to  begin  writing 
“National  Specification”  document  for  MCM’s. 

Attended  RELTECH  Subcommittee  Meeting,  New  Orleans,  LA  1 1/5/93. 

Applications  task:  Provided  ground  rules  for  50  ohm  impedance  thin-film  (joint  with  design). 

Interconnection  standards  for  MCM-C  and  MCM-D  top  surface  design  have  been 
proposed.  Ground  rules  include: 

C4  pad  size  and  pitch 
Wirebond  pad  size  and  pitch 
TAB  pad  size  and  pitch 
Edge  I/O  pad  size  and  pitch 

Minimum  allowable  clearance  between  adjacent  devices. 

Die  attach  pad  size  and  design 

Don  Bouldin  (University  of  Tennessee  -  Knoxville):  Discussed  his  flip-chip  infrastructure 
activities.  Agreed  to  provide  support  for  MCM  activities  through  our  technology 
offerings. 

5.4.3  Interconnection  Technology  Conclusions 

Most  conference  activity  has  been  related  to  materials  science  aspects  of  MCM  technology.  By 
participating  in  these  forums,  we  have  kept  abreast  of  developments  that  may  enable  low  cost 
MCM-D  in  the  future  and  shared  knowledge  on  some  of  the  factors  that  influence  long-term 
durability  and  reliability  of  MCM  structures. 

Interactions  with  RELTECH  have  had  an  influence  on  the  design  of,  and  the  test  plan  for,  the 
technology  demonstration  vehicle.  We  have  also  convinced  RELTECH  that  electrical  and 
mechanical  performance  of  the  C4  interconnections  is  not  a  concern  under  conditions  in  which 
IBM  products  are  qualified. 
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The  activities  described  above  have  led  to  participation  in  national  level  conference  and  workshop 
planning  conunitees  that  will  influence  the  direction  of  MCM  research  and  development.  Our 
participation  in  the  university  workshop  activities  has  allowed  us  to  influence  the  direction  of 
research  toward  solving  technological  problems  relevant  to  MCM  fabrication. 

5.5  Infrastructure  Conclusions 

Significant  technical  contributions  and  discussions  were  held  within  industry  conferences  and 
meetings  with  other  organizations.  This  helped  further  advance  the  MCM  infrastructure  though 
out  the  industry. 
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6.0  APPLICATION  DEMONSTRATION 


The  objective  of  the  Applications  task  was  to  select  MCM  applications  from  OEM  customers  that  would 
demonstrate  the  foundries  design,  build,  and  test  capabilities,  and  would  also  provide  the  customer  with  a 
beneficial  packaging  solution.  Substrate  Technology  from  IBM  Microelectronics  East  Fishkill  packaging 
foundry  was  used  as  the  base  to  assemble  the  modules,  with  die  attach,  test,  and  encapsulation  being  done  at 
the  IBM  facility  in  Poughkeepsie,  N.Y..  The  technology  offered  was  the  same  as  what  is  currently  available  to 
internal  IBM  customers,  and  made  accessible  to  the  customer  by  the  development  of  the  design  kits  and  test 
strategies  discussed  in  this  report.  The  applications  were  staggered  in  time  to  allow  for  the  development  of 
the  various  design  kits  and  to  make  the  most  efficient  use  of  the  ASEM  personnel.  After  the  selection  of  the 
applications,  the  applications  tasks  were  as  follows: 

►  Work  with  customer  to  develop  MCM  application 

►  Import  netlist  into  design  tools  at  IBM  (as  necessary) 

►  Release  design  into  Manufacturing 

►  Verify  success  of  substrate  build  by  comparing  to  customer  netlist 

►  Prepare  die  for  assembly  (Flip  Chip) 

►  Assemble  die  to  Substrate 

►  Demonstrate  all  interconnects  are  complete 

►  Encapsulate  module  with  appropriate  cap/heatsink 

In  all  cases,  the  functionality  of  the  module  was  not  tested  by  IBM,  and  could  not  be  guaranteed  due  to  the 
absence  of  Known  Good  Die. 
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6.1  CUSTOMER  SURVEY 

6.1.1  Selection  Criteria 


The  candidates  for  the  Application  Demonstration  Vehicles  (ADV)  were  screened  based  on  a  set  of 
predefined  criteria  listed  in  Table  6-1.  The  criteria  were  established  to  guarantee  timely  demonstration  of 
ASEM  program  objectives  and  fit  IBM-Microelectronics  Division  product  offerings.  The  list  of  application 
candidates  were  further  screened  based  on  the  business  case,  strategic  value,  and  timftliness  in  all  cases  the 
application  conditions  for  the  end  product,  assuming  manufacturing  volumes  were  realized,  were  used  to  size 
the  manufacturability  and  reliability  of  the  design.  Manufacturing  volume  pricing  was  also  compared  to 
customer  objectives  to  validate  the  business  case  for  the  product. 

6.1.2  Methods  of  Customer  Contact 

The  companies  and  individuals  contacted,  and  applications  reviewed  during  the  selection  process  was 
extensive^  Over  25  potential  customers  were  contacted  who  had  potential  MCM  applications.  In  addition,  a 
number  of  potential  customers  contacted  IBM  directly,  based  on  referrals  or  conference  contacts  Initial 
contact  was  primarily  made  from  IBM  to  the  customer  as  follows: 

Call  placed  to  customer/company  requesting  points  of  contact  for  discussion  of  multichip  modules 
*■  Prime  contact  established. 

*  Explanation  of  ASEM  contract  and  criteria  for  application. 

►  Review  with  ASEM  Application  team  to  determine  fit  to  ASEM  goals. 

*■  Customer  visit  to  review  details  of  program  and  application. 

A  complete  customer  list  is  contained  in  the  "Demonstration  Plan"  CLIN  0002AS,  July  28, 1993. 
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ATTRIBUTE 

CRITERIA 

NUMBER  OF  DEVICES 

2-16 

TYPE  OF  DEVICES 

CMOS 

TYPE 

DIGITAL 

CHIP  POWER 

10  Watts  Max. 

PACKAGE  TECHNOLOGY 

MCM-C,  MCM-D 

MODULE  SIZE 

IBM  Standard  sizes  up  to  127  mm  square 

ENCAPSULATION 

Hermetic,  Non-Hermetic 

MODULE  POWER 

20  Watts  Max. 

COOLING 

Air  Cooled 

DEVICE  ATTACH 

Flip  Chip,  Wire  Bond,  TAB 

MODULE  ATTACH 

Pin  Grid  Array  -  0. 100"  Interstitial  grid 

Surface  Mount  Array  -  0.050"  grid 

Edge  Connect  -  0.5mm  pitch 

Ball  Grid  Array  -  0.050"  grid 

DESIGN  SYSTEM 

CADENCE 

MENTOR 

TEST 

ToKl^/:  i.  a _ _ _ ^  ^  • 

BIST,  Boundary  Scan 

Table  6-1:  Application  Selection  Criteria 


6.2  SELECTED  APPLICATIONS  OVERVIEW 


The  candidates  selected  as  Application  Demonstration  vehicles  are  SUN  MICROSYSTEMS,  the  AIR 
LOGISTICS  CENTER  AT  MCCLELLAN  AFB,  and  NATIONAL  SEMICONDUCTOR  These  three 
candidates  are  selected  based  on  a  best  fit  to  the  selection  criteria,  the  timeliness  of  the  application,  and  its 
ability  to  demonstrate  unique  aspects  of  the  IBM  technology  (refer  to  Table  6-2).  Detailed  descriptions  of 
each  application  will  be  described  in  the  following  sections. 


SUN 

MICROSYSTEMS 

McClellan  air 
FORCE  BASE 

NATIONAL 

SEMICONDUCTOR 

DESIGN  ENTRY 

COMPLETED  LOGIC 

COMPLETED 

PHYSICAL 

COMPLETED  LOGIC 

DESIGN  FORMAT 

CADENCE  ALLEGRO 

CADENCE  ALLEGRO 

EDIFNETLIST 

DIE  SUPPLY 

CUSTOMER 

SUPPLIED  OEM  DIE 

THIRD  PARTY 
SUPPLIED  OEM  DIE 

NATIONAL 

SEMICONDUCTOR 

DIE 

DIE  ATTACH 

METHOD 

FLIP  CHIP  -  IBM 
DESIGN 

WIRE  BOND 

FLIP  CHIP  - 
CUSTOMER  DESIGN 

CARD/BOARD 

ATTACH 

PIN  GRID  ARRAY 

PIN  GRID  ARRAY 

BALL  GRID  ARRAY 

ENCAPSULATION 

NON-HERMETIC 

HERMETIC 

NON-HERMETIC 

INTERCONNECT 

TEST 

JTAG  1149.1 

NON  JTAG 

PHYSICAL 

INSPECTION 

KNOWN  GOOD  DIE 

IBM  KGD  PROCESS 

NO 

NO 

TEST  SOCKET 

AMP  "TAZ" 
CONNECTOR 

AMP  "TAZ" 
CONNECTOR 

IBM  BGA/CGA  TEST 
SOCKET 

Table  6-2:  Technology  Attributes  of  the  Application  Demonstration  Vehicles 
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6.3  SUN  MICROSYSTEMS 

6.3.1  Product  Development 


6.3.1.1  Business  Development  Description 

The  first  of  the  application  demonstration  vehicles  was  designed  and  built  for  Sun  Microsystems,  Inc..  Sun 
approached  the  IBM  East  Fishkill  foundry  to  better  understand  the  foundry's  capabilities.  IBM  proposed 
building  an  MCM  for  Sun,  and  looked  to  find  a  fit  for  the  ASEM  project.  The  10  chip  SPARC  MCM  was 
selected. 


Sun  s  objective  is  to  be  able  to  replace  an  existing  single  chip  module  card  with  a  card  of  the  same  size 
containing  two  multichip  modules.  Sun  had  already  completed  a  design  for  the  multichip  module  using  the 
Cadence  Allegro  design  system,  and  die  were  available  in  wafer  form  for  use.  Since  space  was  one  of  the  key 
drivers  for  the  MCM,  flip  chip  bumping  was  the  front  up  approach.  In  parallel  with  the  Flip  Chip  sizing  the 
™e™f  als0  laid  out  assuming  wire  bond  for  all  the  die,  as  well  as  a  layout  which  assumed  wire  bond  for 
the  SRAM  s  and  Flip  Chip  for  the  Cache  Controller  and  Microprocessor.  The  only  design  that  met  the  size 
requirements  and  could  be  cooled  to  the  required  chip  junction  temperatures  was  the  all  Flip  Chip  approach. 


6.3.1. 2  Sun  Multichip  Module  Description 

The  application  is  a  50MHz  Multichip  module,  with  logic  designed  by  Sun  Microsystems,  Inc.  containing  two 
Texas  instruments  Devices,  the  Viking  Microprocessor  and  Mbus/Xbus  Cache  Controller,  and  eight  Micron 
Synchronous  128k  x  9  SRAM's.  Six  0.  luF  decoupling  capacitors  are  also  included  in  the  design.  The 
substrate  is  a  ceramic  pm  grid  array,  64mm  x  44mm,  with  a  non-heimetic  lid  and  heatsink  The  total  module 
power  is  20  watts  maximum,  with  the  Viking  die  having  a  worst  case  power  of  10  watts  with  a  maximum 
power  density  of  4  watts/cm2.  For  testmg  purposes,  a  Tool  Actuated  Zero  Insertion  Force  (TAZ)  fixture  was 
procured  for  this  application. 


The  rectangular  shape  of  the  substrate  provided  a  very  high  packaging  density,  with  little  wasted  space  on 
the  device  side  of  the  substrate.  The  flip  chip  design  provided  greater  than  70%  silicon  packing  efficiency  in 
the  active  device  area  of  the  substrate.  A  sealing  area  on  the  perimeter  of  the  substrate  provides  the  necessary 
real  estate  for  placmg  a  non-hermetic  lid.  If  required,  this  area  can  be  metallized  to  provide  a  hermetic  seal 
All  wmng  is  contamed  within  the  substrate  so  that  the  I/O  connections  to  the  board  can  be  made  from  the  ' 
MCM,  which  m  this  case  is  provided  by  a  Pin  Grid  Array  (PGA),  but  could  also  be  by  Ball  Grid  Array 


The  substrate  is  manufactured  as  multiple  "ups"  on  the  ceramic  laminate  with  no  wasted  ceramic  thus 
providing  die  most  cost  efficient  design.  The  devices  were  arranged  on  the  module  to  provide  the  shortest 
path  lengths  possible  between  the  die.  The  worst  case  path  length  was  less  than  3cm,  with  the  most  critical 
nets  kept  as  short  as  possible.  The  substrate  groundrules  are  designed  to  provide  a  50  ohm  impedance  match 
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Figure  6-1:  Sun  Microsystems  Multichip  Module  Top  and  Bottom  Surface  Layout 


6.3.2  Sector  Activity 


6.3.2.1  Process  Overview 

The  development  of  the  MCM  began  with  a  preliminary  hardcopy  input  from  Sun  Microsystems,  Inc. 
describing  the  physical  and  power  attributes  of  the  devices  to  be  packaged.  This  information,  along  with  a 
description  of  the  system  environment  and  physical  restriction,  was  used  to  generate  a  first  pass  proposal. 
Working  with  Sun,  the  application  was  refined  to  provide  the  most  manufacturable,  cost  efficient  design, 
while  satisfying  Sun  s  requirements.  During  each  step  of  the  process,  IBM  engineers  from  development  and 
manufacturing  provided  input  to  the  technical  feasibility  and  manufacturability  of  the  MCM  package.  Any 

changes  to  the  package  were  reviewed  with  Sun  to  insure  compatibility. 

Upon  receipt  of  the  netlist  from  Sun  Microsystems,  Inc.  the  development  of  the  MCM  proceeded  along  five 
concurrent  paths:  electrical  and  physical  design  of  the  substrate;  thermal  analysis  and  design  of  encapsulation 
hardware;  Flip  Chip  wafer  bumping;  module  interconnect  test;  and  module  functional  test.  Each  of  the  five 
areas  proceeded  with  the  concurrent  engineering,  which  crossed  company  boundaries,  such  as  the  inclusion  of 
test  pins  in  the  substrate  design  to  facilitate  module  debug.  To  simplify  module  debug,  an  AMP  connector 
was  procured  which  provided  the  capability  to  mount  and  demount  modules  into  the  test  board,  without 
having  to  solder  and  desolder  the  modules.  The  design  of  the  connector  and  its  associated  actuation  device 
was  generated  based  on  the  physical  design  of  the  module  and  test  card. 
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To  guarantee  manufacturability  of  the  module,  a  design  review  meeting  is  standard  practice  so  that  all 
manufacturing  units  responsible  for  the  build  of  the  module  can  review  and  concur  with  the  design.  Included 
in  the  design  review  process  are  representatives  from  the  substrate  build,  bond,  assemble,  and  test  areas.  A 
design  review  is  also  held  between  the  companies  at  critical  stages  of  the  project,  to  insure  the  module  and  the 
functional  test  preparation  converge. 

6 .3.2. 2  Substrate  Design 

6.3.2.2.1  Design  Support 

The  Sun  Multichip  module  was  designed  using  the  Cadence  7.0  Allegro  Design  System.  The  first  part  of  the 
design  process  is  the  creation  of  the  padstacks  and  symbols  for  the  various  components,  using  their  respective 
editors  within  the  Allegro  Design  System.  The  amount  of  time  required  to  create  the  padstacks  for  this 
substrate  was  less  than  5%  of  the  entire  design  cycle.  The  creation  of  symbols  for  the  Sun  module,  ASCII 
files  were  created  to  automatically  place  pins  and  thus  reduce  a  portion  of  the  cycle  time. 

63J2J2.2  Logic  Entry  Level 

The  logic  input  for  this  module  was  supplied  as  a  third  part}'  ASCII  netlist  from  Sun  Microsystems,  Inc. 

Clean  logic  input  is  dependent  upon  the  netlist  and  the  created  symbols  being  consistent.  If  this  isn't  the  case, 
then  several  attempts  at  leading  the  logic  input  must  be  attempted.  If  the  data  is  provided  in  a  different  input' 

usually  transformation  and  reformatting  is  required  and  this  will  contribute  significantly  to  the  overall  desien 
cycle  time. 

Once  the  netlist  was  inputted  into  the  Allegro  system,  the  necessary  level-to-level  connections  are  generated 
Tins  was  minimal  in  the  overall  design  cycle  time.  The  next  portion  of  the  design  effort  was  the  placement  of 
the  created  symbols.  A  proposed  outline  of  symbol  locations  was  provided  to  the  designer  and  this  outline 
was  to  be  used  as  the  skeleton  for  the  automatic  placement  for  the  symbols.  With  the  symbol  outline,  the 
placement  of  the  symbols  occurred  in  minute 

One  part  of  the  designer's  responsibility  which  adds  to  the  cycle  time  is  any  manual  type  of  interaction  with 
the  design  system.  On  the  Sun  module,  the  manual  interactions  involved  redistribution  from  off-grid  to  on- 
grid  locations  for  the  MXCC  and  Viking  devices  and  overflow  routing  in  nets  which  the  automatic  router  can 
not  complete  the  connection.  These  two  tasks  represent  a  major  percentage  to  the  overall  design  cycle  time 
(at  least  33  /o).  For  rapid  prototyping  where  turn  around  time  is  of  utmost  importance,  the  nets  can  be 
connected  almost  entirely  by  the  router,  which  was  the  case  in  the  Sun  prototype.  The  design  was  routed  in 
tbreeX-Y  plane  pairs,  but  was  followed  up  with  a  two  X-Y  plane  pair  design,  with  hand  routing  of  multiple 
overflow  nets.  In  volume  manufacturing,  it  is  much  more  cost  effective  to  wire  the  substrate  in  as  few  layers 
as  possible  where  the  material  and  build  cycle  time  savings  can  warrant  the  added  design  time. 

6.3.2.2.3  Release 

Once  the  design  was  completed,  the  top  and  bottom  surface  design  drawings  were  imported  to  a  CADAM 
tool  where  the  substrate  tolerances  were  placed  on  the  drawings.  A  substrate  layer  drawing  was  also 
generated,  describing  the  function  of  each  of  the  individual  substrate  layers.  The  drawings  were  placed  on  the 
IBM  part  number  list,  controlled  by  a  Product  Engineer,  with  all  changes  requiring  concurrence  by  the 
engineering  team  responsible  for  the  project  (Team  consists  of  Manufacturing,  Product,  Development,  and 
pplications  Engineers).  The  substrate  was  not  built  on  the  Manufacturing  line,  but  on  the  prototype  line 
using  an  Electron  Beam  tool  (E-BEAM),  which  produces  substrate  layers  without  using  metal  masks.  The' 
design  data,  normally  sent  through  the  standard  direct  release  process,  was  instead  provided  to  the  Engineer 
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responsible  for  the  Electron  Beam  (E-BEAM)  tool.  The  engineer  converted  the  data  to  a  tool  format  and 
proceeded  with  the  build  of  the  module. 

6. 3.2.3  Substrate  Prototype  Build 

The  ceramic  green  sheets  used  for  the  multilayer  ceramic  were  personalized  using  a  high  power  electron  beam 
system,  or  E-BEAM.  This  quick  turn-around,  high  precision  and  high  resolution  system  provides  an  ideal 
P^ssforthe  timely  development  of  specialized  ceramic  packages  in  prototype  volumes.  This  is  the  result 
ot  E-BEAM  s  ability  to  personalize  green  sheets  using  a  direct  write  instead  of  a  glass  master  and  metal  mask 
as  the  typical  personalization  methods  involving  paste  screening  use.  By  using  the  E-beam  for  prototype 
build,  the  NRE  savings  for  the  substrate  build  is  approximately  80%  and  the  tum-around  time  savings  is 
approximately  33%  over  traditional  punch  and  screening  methods.  * 

Once  the  greensheets  were  personalized  by  the  Ebeam  tool,  they  were  stacked,  laminated,  and  sintered 
according  to  conventional  ceramic  substrate  fabrication.  The  initial  substrate  lot  was  tested  for  capacitance 
and  the  'chip  to  chip'  and  'chip  to  I/O'  connections  were  tested  and  compared  to  the  netlist  to  verify  that  the 
substrate  hardware  completely  matched  the  netlist.  The  parts  were  then  overplated  with  nickel  and  a  thin 

layer  of  gold  to  provide  a  wettable  surface  for  device  attach.  Thick  gold  was  not  required  for  the  module  due 
to  the  absence  of  any  wire  bonded  components. 

6.3.2.4  Flip  Chip  Bumping 

63.2.4.1  Design  Considerations 

In  parallel  with  the  substrate  build,  the  Viking  and  MXCC  wafers  provided  by  Sun  Microsystems  Inc.  were 
being  prepared  for  Flip  Chip  (C4)  bumping.  The  periodicity  of  the  Flip  Chip  bumps  is  optimized  at  0.010" 
with  bump  diameters  of  approximately  0.005".  Both  the  Viking  and  MXCC  die  are  designed  for  wire  bond, 
and  the  pitch  for  both  die  was  less  than  what  was  practical  for  flip  chip  bumping.  A  layer  of  wiring  was 
added  to  the  die  to  redistribute  the  I/O  to  the  0.010"  pitch,  with  two  rows  of  bumps  for  the  Viking,  and  three 
rows  for  the  MXCC.  Die  designed  for  flip  chip  eliminate  the  need  for  redistribution  and  also  potentially 
reduce  the  amount  of  silicon  required  for  I/O  interconnection.  The  SRAM's  did  not  require  redistribution 
because  the  wire  bond  pad  periodicity  was  within  the  limits  of  the  bumping  process. 

63.2.4.2  Implementation 

A  layer  of  passivation  was  deposited  on  all  wafers,  vias  opened  to  connect  to  the  underlying  metallization, 

and  the  Flip  Chip  pad  was  formed.  The  Lead/Tin  solder  ball  was  then  formed  on  the  die,  and  the  die  were 
diced  and  picked. 


In  keeping  with  Sun's  objective  of  having  the  capacity  of  placing  two  multichip  modules  on  the  current  Mbus 
card,  the  flip  chip  bumping  of  all  the  die  significantly  reduced  the  required  substrate  area  by  eliminating  the 
need  for  wire  bond  pads.  Flip  chip  bumping,  coupled  with  the  advanced  thermal  compound  between  the  die 
and  cap,  provided  a  very  efficient  thermal  path  without  having  to  reduce  substrate  wire  density,  necessary 
when  thermal  vias  or  heat  studs  are  required.  The  area  array  capability  of  the  flip  chip  technology  was  more 
than  sufficient  to  handle  the  I/O  of  the  microprocessor  and  Cache  controller. 
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6, 3.2.5  Module  Design 


6.3.2.5.1  Cap  and  Heatsink  Development 

The  MCM  substrate  design  was  influenced  by  the  need  to  cool  the  MXCC  and  Viking  die  to  an  acceptable 
temperature  which  provided  both  performance  and  reliability.  The  devices  were  placed  adjacent  to  each  other 
to  minimize  the  path  lengths  between  the  die.  They  were  oriented  on  the  module  to  receive  parallel  airflow  so 
that  there  would  be  no  air  heating  effect  from  one  die  to  the  next.  As  mentioned  previously,  an  advanced 
thermal  compound  was  used  between  the  chip  and  cap  to  provide  a  veiy  efficient  thermal  path.  With  a  very 
low  internal  thermal  resistance  from  the  back  of  the  die  to  the  cap,  the  bulk  of  the  heat  transfer  is  through  the 
die  into  the  cap,  and  out  the  heatsink.  The  gap  between  the  cap  and  die  is  controlled  very  closely  to  minimize 
the  internal  thermal  resistance.  The  SRAM's  and  the  capacitors  do  not  have  thermal  grease  because  the  lower 
power  requirements  of  the  SRAM's  and  capacitors  did  not  create  a  demand  for  thermal  enhancement. 

A  unique  feature  of  the  design  was  the  requirement  to  provide  a  backside  electrical  contact  to  the  die  after 
assembly  of  the  module.  The  MXCC  and  Viking  die  required  a  drain  for  the  backside  bias,  and  since  the 
chips  were  face  down,  the  drain  could  not  be  by  direct  contact  between  the  die  and  substrate.  Two  techniques 
were  considered;  1)  electrically  conductive  thermal  paste  and  2)  A  spring  loaded  contact  between  the  cap  and 
die.  The  thermal  paste  has  been  fabricated  and  tested  for  other  applications,  but  since  the  die  rework  was  a 
requirement  for  the  package,  there  was  concern  that  the  conductive  grease  could  get  under  the  die  and  cause  a 
potential  short  between  Flip  Chip  I/O  pads.  Non-reworkable  modules  would  have  an  encapsulant  below  the 
die,  which  would  prevent  the  conductive  grease  from  contacting  the  I/O  connections.  The  spring  contact  was 
chosen  and  prototype  caps  were  built  and  demonstrated  successfully. 

The  system  application  conditions  are  consistent  with  desktop/deskside  environmental  conditions.  During  the 
thermal  modeling  and  design  of  the  module,  system  airflow,  inlet  air  temperatures,  physical  size  restrictions, 
and  altitude  adjustments  had  to  be  considered  to  predict  worst  case  chip  junction  temperatures.  Based  on  the 
above  worst  case  system  definitions,  an  external  thermal  resistance  was  calculated  that  would  meet  the 
maximum  chip  junction  temperature  limit.  Commercially  available  heatsinks  were  sought,  but  none  could  be 
found  which  met  the  requirements,  so  a  custom  heatsink  was  designed.  The  heatsink  was  designed  to 
overhang  the  module  because  the  demountable  connector  chosen  for  prototype  evaluation  increased  the 
overall  height  of  the  assembly  by  9  mm,  thereby  reducing  the  available  height  in  the  system  for  the  module 
Once  the  need  for  the  demountable  connector  is  eliminated,  the  heatsink  will  make  better  use  of  the  Z-axis 
height  in  the  system. 

6.3.2.5.2  Release 

The  module  release  process  for  the  Sun  MCM  was  the  most  complex  of  the  Application  Demonstration 
vehicles.  A  unique  cap  and  heatsink  were  designed  to  fit  the  64mm  x  44mm  size,  and  CADAM  drawings 
were  generated  for  both.  The  drawings  were  used  by  the  vendor  to  build  the  hardware,  and  were  also  used  to 
develop  the  overall  module  assembly  drawings.  As  with  the  substrate  drawings,  the  module  drawings  were 
assigned  Part  Numbers,  which  are  on  record  and  require  the  necessary  engineering  team  concurrence  prior  to 
change.  Documentation  was  also  generated  for  the  test  sockets,  but  Part  Numbers  were  not  generated.  The 
Flip  Chip  pad  layouts  were  also  documented  with  CADAM  drawings. 

6.3.2.6  Module  Assembly 

Once  both  the  substrate  and  bumped  die  were  available  for  assemble,  a  Flip  Chip  furnace  profile  was 
established  for  the  module,  and  the  die  were  reflowed  to  the  substrate.  The  capacitors  were  also  reflowed  to 
the  substrate  subsequent  to  the  die  to  1)  preserve  their  electrical  performance,  and  2)  be  consistent  with 


6-9 


temperature  hierarchy  of  the  solders  used  for  Flip  Chip  (97Pb/Sn)  and  the  passives  (63Pb/Sn).  After  the  die 
were  bonded  to  the  substrate,  the  parts  were  tested  to  guarantee  all  the  Chip  to  Substrate  I/O  were  electrically 
connected.  This  was  to  insure  that  the  die  bumps,  redistribution,  and  substrate  I/O  were  making  the  correct 
contacts.  Once  tested,  the  modules  were  encapsulated  with  a  thermally  conductive  grease  between  the  die  and 
the  module  lid,  and  the  heatsink  was  placed  on  top  of  the  module. 

The  connector  chosen  for  the  evaluation  was  an  AMP  Tool  Actuated  Zero  Insertion  Force  (TAZ)  connector. 

It  was  designed  to  accommodate  a  25  x  25  array  of  pins.  A  unique  actuation  tool  was  designed  which 
provided  sufficient  clearance  for  the  heatsink  during  actuation.  The  connector  was  solder  reflowed  to  the  card 
similar  to  a  PGA  package,  and  the  MCM's  were  inserted  in  the  connector  and  actuated.  Once  testing  of  the 
module  was  complete,  the  module  is  removed  from  the  connector,  and  the  process  is  repeated  on  the  next 
module. 

6.3.2.7  Interconnect  Test 

The  Sim  Super  Sparc  Mbus  MCM  assembly  interconnect  test  was  generated  and  debugged  concurrently  with 
the  installation  and  debug  of  the  Victory  software  package.  This  combined  process  complicated  many 
aspects  of  the  overall  process  because  of  uncertainty  in  the  test  data  input  to  the  system.  The  initial  test 
development  and  debug  process  was  done  using  a  circuit  card  version  of  the  Mbus  MCM  and  was  tested 
solely  through  the  TAP  port  using  the  ASSET  scan  port  driver.  The  Asset  tool  also  includes  Victory  package 
as  its  ATPG  resource.  The  ten  chip  set  used  in  ADV1  consists  of  8  -  9  bit  by  256k  SRAMS  which  is 
organized  as  a  64  bit  plus  9  bit  parity  memory,  a  1 149. 1  compatible  Super  Sparc  64  bit  RISC  processor  and 
an  1 149. 1  compatible  MXCC  Mbus  Cache  controller.  The  signal  architecture  of  the  MCM  is  illustrated  in 
Figure  6-2  and  shows  the  basic  signal  topology  of  the  MCM.  Physical  features  added  to  the  MCM  for 
improved  testability  include  an  observe  point  in  the  1 149. 1  scan  chain  between  the  RISC  and  the  MXCC,  an 
observe  point  on  one  of  the  SRAM  parity  lines  and  module  I/O  access  to  the  SRAM  output  enable  control 
signal. 


Viking 
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Figure  6-2:  AD VI  -  Module  Signal  Architecture 
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6.3.2.7.1  Test  Plan 

The  test  plan  for  the  AD  VI  module  consists  of  a  parametric  test  for  power  ground  shorts  and  an  assembly 
verification  interconnect  test  which  assures  continuity  of  all  bonds.  Test  data  was  supplied  by  Sun  in  the 
form  of  hard  and  softcopy  documents  and  included  device  BSDL  and  an  EDIF  netlist.  The  EDIF  netlist  was 
for  the  MBUS  card  while  the  netlist  used  for  the  MCM  itself  would  be  obtained  internally  from  the  Cadence 
physical  design  tool.  Hardware  descriptions  for  the  SRAM  devices  was  obtained  from  hardware  specification 
s  eets  published  by  the  die  supplier  (Micron.)  The  interconnect  test  patterns  are  generated  automatically  and 
manu^  dependent  0n  available  1 149  1  test  resources.  A  prototype  board,  tested  through  its  TAP  port  using 
the  ASSET  tool,  was  to  be  used  for  database  verification.  The  final  MCM  product  is  interconnect  tested 
using  the  flexible  hardware  fixturing  and  a  DAS9200  based  scan  tester.  Die  supplied  in  wafer  form  by  the 
customer  are  not  considered  KGD.  C4  bumped  die  are  to  be  mounted  on  temporary  chip  carrier  single  chip 
modules  for  production  of  known  good  die.  Functional  test  of  the  module  is  to  be  performed  by  the  customer 
using  a  system  level  self  test  after  insertion  of  the  module  into  a  system  level  MBUS  card. 


6.3.2.7.2  Test  Pattern  Generation 

Automatic  Test  Pattern  Generation  was  used  to  provide  test  coverage  for  all  interconnects  between 
49. 1  devices  on  the  MCM.  Although  the  reduced  pin  TAP  port  was  used  for  test  access,  a  1 149. 1  based 
test  fixture  was  used  to  observe  and  stimulate  all  primary'  MCM  I/O.  Access  to  the  MCM  primary  I/O  was 
enabled  by  embedding  the  MCM  inside  a  "ring"  of  1 149. 1  compliant  bus  transceivers.  The  test  fixture 
BSDL  descriptions  and  netlist  connectivity  were  combined  with  the  MCM  database  to  enable  ATPG 
interconnect  testing  of  the  primary  MCM  I/O.  For  this  product,  ATPG  has  provided  open  and  short 
coverage  for  approximately  60%  of  the  total  267  nets  and  partial  coverage  (approximately  66%  complete 
sborts) for  the  remaining  nets.  Nets  not  fully  covered  by  Virtual  Interconnect  Test  Generation 
(VITG)  were  the  SRAM  branches  of  address  and  data  nets  and  SRAM  control  signal  group  nets  with  only 
smgle  ended  boundary  scan  cells.  Test  coverage  was  extended  to  the  partially  covered  nets  using  test  patterns 
generated  manually  from  data  sheets  and  the  Victory  Virtual  Component  Cluster  Test  (VCCT) 

To  minimize  any  delays,  debugging  of  the  Victory  test  software  and  the  test  generation  process  was 

acwmphshed  concurrently  using  a  printed  circuit  board  version  of  the  MCM.  The  card  was  tested  using  the 
AobET  test  system  from  Texas  Instruments. 


cd  ?at  the^RAM  data  bus  drivers  were  not  envied  during  VITG,  a  value  was  forced  onto  the 
SRAM(s)  Output  Enable  receivers.)  The  forced  signal  level  was  accomplished  by  altering  the  BSDL 
descriptions  for  both  of  the  1 149. 1  devices  on  the  net.  One  side  of  the  net  was  changed  to  hide  the  driver 
control  from  Victory  while  ensuring  the  output  enable  bit  was  never  altered  from  its  disable  value  The  other 
side  of  the  net  was  altered  to  always  drive  the  correct  value  onto  the  net.  The  result  was  unique  BSDL 
descriptions  for  the  VITG  and  VCCT  portions  of  test  program 


VITG  MBUS  Card  Test  Results 

After  a  great  deal  of  preliminary  learning  and  adaptive  efforts,  the  MBUS  card  was  successfully  tested  using 

an  automatically  generated"  SVF  file.  The  BSDL  descriptions  included  a  manually  generated  BARE  DIE 

pinmap  and  were  debugged  in  an  iterative  process  by  successively  generating  the  ATPG  portion  of  the  card 
mterconnect  test,  then  testing  the  card  and  finding  the  root  cause  of  test  failures.  Since  the  card  was  "known 
good  most  failures  could  be  ascribed  to  hardware  description  errors.  A  summarv  of  the  coverage  provided 
by  the  ATPG  portion  of  the  test,  valid  for  both  the  MBUS  card  and  MCM,  is  provided  in  Table  6-3.  The 
ttme  spent  on  the  card  was  very  worthwhile  since  numerous  errors  were  discovered  in  the  supplied  BSDL 
descriptions  and  uncovered  several  undocumented  Victory  problems.  Overall  the  ATPG  and  BSDL 
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environment  using  Victory  has  great  promise  of  providing  a  quick  TAT  and  low  cost  assembly  test  process. 

As  previously  stated,  VCCT  testing  was  performed  individually  on  all  eight  SRAMs.  The  original  test  plan 
treated  all  eight  SRAMs  as  a  single  cluster,  however  VCCT  testing  (per  Victory  release  2.1)  had  to  be 
performed  on  a  component-by-component  basis.  A  consequence  of  this  component  test  methodology  was 
that  a  unique  Victory  PFA  and  ACT  file  was  required  for  testing  each  SRAM  on  the  brassboard  and  MCM. 


OPEN  /  SHORT  COVERAGE 

VITG 

VITG  +  VCCT 

Fully  covered 

131 

242 

Partially  covered 

111* 

0 

Shorts  covered 

4 

4 

Some  opens  covered 

3 

3 

Not  covered 

12 

12 

Covered  by  TAPIT 

6 

6 

(Number  of  covered  nets  /  total  nets)  x  100 
*  Derated  by  approximately  one  third 

81.4% 

95.5% 

Partially  covered  nets  may  have  an  uncovered  branch  or  may  be  single  ended. 

A  single  ended  net  refers  to  a  net  having  only  one  observe/stim  point. 

Partially  covered  nets  are  derated  by  the  fraction  of  branches  not  covered. 

Table  6-3:  ADV(l)  Interconnect  Test  Coverage 


Manual  Test  Pattern  Generation 

A  specific  test  data  file  was  manually  generated  from  data  specification  sheets  for  each  SRAM.  Unique  data 
was  written  to  the  SRAM  memory  and  addresses  using  walking  patterns  selected  to  test  each  separate  address 
line.  The  tests  check  for  opens  and  shorts  between  every  two  I/O  nodes  on  the  SRAM.  Because  known  good 
die  was  assumed,  extensive  in  circuit  tests  were  not  conducted  to  verify  internal  SRAM  integrity.  Data  read 
back  from  the  SRAMs  is  used  to  determine  interconnect  integrity.  The  output  enable,  write  enable  lines  were 
set  by  input  vector  patterns  but  because  these  are  synchronous  memories  a  clock  also  had  to  be  applied  to 
initiate  actions  and  cycle  the  SRAM  functionality.  Checking  of  control  signals  and  clock  interconnect 
continuity  is  a  by  product  of  the  correct  functioning  of  the  SRAM  test  data  patterns.  Parity  bits,  as  defined  in 
the  module  design,  are  actually  the  ninth  data  bit  for  these  particular  memories  and  were  tested  accordingly. 
The  SRAM  test  patterns  start  by  initializing  the  lowest  address  to  zeros  and  the  highest  address  to  ones. 

Then  unique  9  bit  words  were  written  to  addresses  selected  by  a  walking  one.  On  readback,  a  short  to 
ground  or  an  open  pulled/floating  low,  in  the  address  bus  would  be  identified  by  the  associated  data  being 
written  to  address  zero  instead  of  the  planned  address.  If  a  short  was  to  the  power  rail  or  an  open 
pulled/floating  high,  the  word  would  be  written  into  where  it  was  expected  to  go  into  memory,  however  the 
complement  pattern  set  would  write  the  unique  word  into  the  all  ones  address  rather  than  the  correct  address 
thus  allowing  a  definitive  diagnostic.  Referring  to  data  line  interconnects,  either  a  short  or  an  open  in  a  data 
bit  would  be  reflected  by  incorrect  data  on  readback  from  either  the  original  or  complemented  data. 
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After  a  significant  investment  of  time,  an  SVF  file  was  produced  which  successfully  applied  a  walking  ones 
test  to  the  MBUS  card  SRAMs.  The  knowledge,  and  detailed  process  required  to  use  the  VCCT  tool  was 
then  applied  to  the  database  for  the  MCM. 

63.2.7*3  Known  Good  Die  (KGD) 

The  die  used  in  the  ADV1  design  are  not  considered  as  KGD.  For  each  die  type,  wafers  were  received  from 
the  silicon  fabricators  with  either  a  map  or  dot  marked  indicator  of  die  passing  the  wafer  level  sort  test.  Since 
wafer  level  sort  testing  is  usually  not  an  at-speed  test  and  is  not  exhaustive,  the  probability  of  defective  die 
was  assumed  to  be  quite  high.  This  assumption  needed  to  be  made  because  the  wafer  suppliers  were  either 
unwilling  or  unable  to  supply  the  expected  versus  actual  yield  information  needed  to  plan  assembly  yields. 
Also,  for  the  Super  Sparc  and  MXCC  die,  the  manufacturer  was  unsure  if  the  1 149. 1  resources  were 
adequately  tested  during  wafer  sort  which  directly  impacted  the  ability  to  deliver  known  good  MCM 
assemblies.  Additionally  each  of  the  die  used  in  the  ADV1  design  were  C4  bumped  and  in  the  case  of  the 
Super  Sparc  and  MXCC  die,  had  redistribution  metal  applied  to  transform  the  wirebond  footprint  to  an  area 
array  prior  to  C4  bumping.  The  added  level  of  complexity  and  added  potential  sources  of  error  introduced  by 
bumping,  redistribution  and  lack  of  expected  yield  data  suggested  to  us  the  need  for  a  way  to  isolate  problems 
which  could  and  did  occur. 

Because  the  die  were  all  C4  bumped,  an  intemal(at  the  time)  technology  for  temporarily  attaching  the  die  to 
single  chips  modules  could  be  used  for  testing.  Briefly,  the  temporary  chip  attach  method  uses  spring  force  to 
press  the  die  C4  against  a  contact  pad  which  has  a  proprietary  plated  palladium  dendrite  structure.  The 
dendrites  may  be  formed  on  many  different  material  systems  but  in  this  case  we  used  our  standard  ceramic 
substrate.  Thermal  control  is  provided  by  the  spring  containment  structure  which  has  integral  cooling  fins 
extending  upwards  from  the  ceramic  carrier.  An  example  of  the  TCA  module  package  is  illustrated  in  Figure 
3-10  in  Section  3.4,  Known  Good  Die. 

For  the  Super  Sparc  and  MXCC  die,  the  single  chip  packages  currently  in  use  for  those  products  were 
mimicked,  which  is  a  multilayer  ceramic  PGA  having  SMT  decoupling  capacitors.  The  TCA  module  used  for 
the  SRAMs  was  a  metalized  ceramic  PGA.  The  following  sections  will  describe  the  test  methodology  used 
for  each  of  the  three  different  die  types.  The  test  methodology  focuses  primarily  on  detecting  faults 
associated  with  our  performing  the  interconnect  assembly  verification  test. 

SRAM 

The  TCA  module  used  for  the  SRAMs  was  a  50mm  metalized  ceramic  substrate  with  a  2.54  mm  pin  grid 
array.  The  testing  of  the  TCA  module  was  performed  on  an  IBM  designed  ATE,  at  full  MCM  system  speed 
of  50MHz.  The  test  patterns  were  manually  generated  and  were  directed  at  two  different  fault  types.  The 
first  fault  type  are  faults  that  would  impact  our  ability  to  perform  interconnect  verification  test.  These  vectors 
toggled  the  address  lines  and  memory  locations  which  we  would  be  using  to  verify  assembly  interconnects. 

The  second  set  of  patterns  was  aimed  at  flushing  out  the  most  likely  at-speed  types  of  faults.  The  faults  are 
slow  to  rise/fall  driver/receivers  and  adjacent  pattern  sensitive  faults.  Results  for  the  SRAMs  showed  all  TCA 
die  to  function  properly  for  the  required  functionality  needed  for  the  interconnect  test  and  for  the  base  set  of 
sensitivity  patterns  done  at-speed. 

Super  Sparc  and  MXCC 

The  Super  Sparc  and  MXCC  TCA  modules  were  fabricated  using  50mm  multilayer  ceramic  substrates 
having  293  and  363  pin  grid  arrays  on  1.27mm  centers.  The  I/O  footprint  of  each  of  the  substrates  was  laid 
out  to  be  exactly  the  same  as  the  commercially  available  packaged  SCM  parts.  The  netlists  for  the  substrates 
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was  supplied  by  Sun  Microsystems.  The  TCA  modules  were  also  used  to  verify  BSDL  descriptions  and 
1 149. 1  hardware  functionality  as  a  screen  for  interconnect  assembly  verification  test.  The  TCA  modules 
were  tested  by  socketing  them  into  LIFs  which  had  been  hardwired  to  supply  power,  ground  and  lead-to-lead 
interconnectivity.  The  lead-to-lead  netlist  was  developed  manually  and  interconnected  as  many  nets  as 
possible  in  order  to  test  the  temporary  contacts  and  the  die  drive/receive  circuitry.  The  netlist  and  BSDL 
data  was  used  with  Victory  ATPG  to  generate  the  test  and  the  TI  ASSET  tool  was  used  to  drive  the  test. 
Coverage  for  these  tests  included  all  signal  nets  with  the  exception  of  clocks,  Mbus/Xbus  select  and  the  reset 
line. 


The  TCA  modules  were  also  used  to  establish  or  screen  die  parametric  parameters.  Resistance  measurements 
between  the  power  and  ground  planes  were  not  possible  at  the  die  level  because  of  probing  and  handling 
concerns  and  were  not  possible  at  the  module  level  because  the  power  planes  are  commoned.  The  results  for 
parametric  screening  provided  determination  that  the  Super  Sparc  die  had  a  VCCC  to  GND  resistance  which 
was  well  below  the  level  measured  on  SCM  parts  (100  vs.  5000  Ohms.)  The  specification  values  we 
obtained  from  the  SCM  packages  was  confirmed  by  Sun.  Failure  analysis  on  the  die,  which  consisted  of 
resistance  measurements  taken  before  and  after  removal  of  the  IBM  applied  redistribution,  showed  the  low 
resistance  was  integral  to  the  die.  There  was  no  observed  impact  on  1 149. 1  functionality  due  to  the  low 
resistance  plane.  Sun  was  informed  of  the  finding  and  took  it  under  advisement.  The  MXCC  die  were  all 
observed  to  match  the  parametric  behavior  of  their  corresponding  SCM  parts. 


Results  for  BSDL  description  screening  uncovered  several  errors  in  the  BSDL  descriptions  for  the  Super 
Sparc  and  MXCC  die.  The  errors  were  similar  to  others  observed  during  the  early  ATPG  and  test  vector 
development  but  were  unresolved  because  of  insufficient  diagnostic  resolution.  The  errors  in  the  BSDL  were 
in  this  case  port  descriptions  which  were  switched  in  position.  The  use  of  the  TCA  modules  provides 
unambiguous  results  for  a  device  as  opposed  to  the  results  provided  by  two  or  more  devices  on  a  net.  The 
TCA  process  also  provided  the  ability  to  resolve  several  transcription  errors  which  had  occurred  earlier  in  the 
design  phase  and  had  been  caught  by  1 149. 1  testing  but  not  yet  been  assigned  to  cause. 


63.2.1.4  MCM  Interconnect  Test 

MCM  interconnect  test  used  the  process  and  BSDL  developed  during  the  initial  debug  work  and  TCA  module 
testing.  This  information  was  combined  with  the  MCM  netlist  to  produce  automatically  generated 
interconnect  test  patterns  and  to  format  the  manually  generated  memory  interconnect  test  patterns.  The  SVF 
output  of  the  Victory  tool  was  translated  to  out  tester  format  and  the  product  specific  socket  mounted  in  the 
thermal  cooling  assembly.  For  this  design  the  cooling  assembly  was  adapted  to  provide  backside  grounding 
of  the  Super  Sparc  and  MXCC  die  using  a  pogo  like  spring  contact. 


Test  coverage  for  the  MCM  is  reported  in  Table  6-3  for  both  VITG  and  VITG+VCCT  sections  of  the  test. 
The  1 149. 1  based  test  was  quickly  able  to  detect  and  isolate  open  or  shorts  in  the  MCM  assembly.  Using  the 
test  information  repair  orders  were  generated  and  the  prototype  modules  were  successfully  reworked. 
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6.3.3  Conclusions 


The  selection  of  ^  Sun  MCM  as  the  first  demonstration  vehicle  provided  the  opportunity  to  demonstrate  the 
ability  to  accept  a  Cadence  netlist  into  the  factory.  Since  the  netlist  had  already  been  debugged  by  Sun, 
incoming  design  errors  were  minimized  and  the  substrate  physical  design  proceeded  smoothly. 

The  build  of  the  Sun  Microsystems  Substrate  using  the  E-BEAM  prototyping  tool  was  proven  to  be 
successful  through  testing  the  substrate  per  the  supplied  netlist.  After  the  first  build  of  the  Sun  substrates,  a 
requirement  for  a  separate  power  plane  for  the  Viking  die  was  defined.  Using  the  E-BEAM  tool,  which  does 
not  require  metal  screening  masks,  provided  a  very  easy  path  for  rebuilding  the  hardware.  Once  the  new 
design  was  completed,  the  parts  were  rebuilt  without  incurring  the  Non  Recurring  Expense  charges  of  the 
masks.  The  redesign  was  accomplished  without  changing  the  wiring  layers  or  adding  additional  power  layers 
to  the  substrate.  The  new  voltage  'layer'  was  added  by  partitioning  a  section  of  the  existing  power  plane  below 
the  Viking  die.  The  design  m  the  44mm  x  64mm  format  was  a  new  form  factor  for  the  foundry  Since  then, 
additional  projects  have  made  use  of  the  form  factor,  using  the  same  tools  and  fixtures. 

The  module  was  successfully  interconnect  tested  using  the  1 149. 1  resources  of  the  Super  Sparc  and  MXCC 
die  as  well  as  manually  generated  write/read  cycles  applied  to  the  SRAMS  using  the  available  boundary  scan 
resources.  A  test  coverage  of  95.5%  of  all  possible  nets  was  realized  with  100%  coverage  of  boundary  scan 
accessible  nets.  The  nets  not  covered  consisted  primarily  of  power/ground  nets,  signal  level  control  nets, 
clock  inputs  to  the  large  ASICs  and  mode  select  signals.  If  debug  of  data  integrity  problems  and  Victory 
software  bring-up  are  neglected,  the  test  generation  process  was  straight  forward  and  met  our  expectations. 

Establishing  a  known  good  die  methodology  for  the  Sun  module  was  the  most  critical  accomplishment  of  the 
project.  The  use  of  TCA  for  the  ADV1  MCM  provided  a  useful  means  of  die  isolation  and  access  for 
verification  of  device  BSDL,  single  chip  module  nedists  and  dendrite  contact  verification.  Furthermore  the 
process  yielded  die  which  were  guaranteed  to  function  properly  for  assembly  verification  test.  Tested  Super 
Sparc  and  MXCC  die  used  m  the  final  module  assembly  verification  test  allowed  elimination  of  a  class  of 
diagnostics  0thenvise  wouId  have  bad  t0  be  considered  and  facilitated  a  reduction  in  the  complexity  of  MCM 
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6.4.  SACRAMENTO  AIR  LOGISTICS  CENTER  (SM-ALC) 

6.4.1  Product  Development 


6.4.1. 1  Business  Development  Description 

a  TYrxjf^'^  objective  for  ^  MCM  was  38  replacement  hardware  for  the  existing  Data  Transfer  Module.  The 
ADTM  is  intended  to  be  used  for  transferring  Operation  Flight  Programs  to  the  F- 1 1 1  aircraft  Each 
OperationFhght  Program  (OFP)  is  approximately  5 12K  16  bit  words  of  instruction  code  where  a  total  of 
640K  words  are  actually  needed  when  check-sum  and  variable  initialization  requirements  are  included 
Therefore,  the  ADTM  is  sized  for  640K  16  bit  words  of  program  data  storage.  Current  aircraft  avionics 
require  the  OFP  s  to  be  loaded  into  flight  computers  using  a  magnetic  tape  system  that  is  prone  to 
malfunctions  and  requires  access  to  aircraft  equipment  bays.  The  F-l  1 1  also  has  a  cockpit  socket  which  can 
be  used  to  transfer  the  OFP  mto  the  aircraft  flight  computers  using  an  existing  32K  word  DTM.  The  ADTM 
design  used  the  cockpit  flight  computer  interface  socket  to  load  the  entire  OFP,  eliminating  the  need  for  the 
tape  system  and  replacing  the  limited  capacity  32K  DTMs  with  a  single  ADTM 


6.4.1. 2  Document  of  Execution 

A  document  of  execution  was  generated  describing  the  responsibilities  of  both  IBM  and  Sacramento  ALC 
The  document  contained  descriptions  of  the  module  and  a  schedule  of  key  program  activities. 


6.4.1  *3  Hardware  Description 

The  Advanced  Data  Transfer  Module  (ATM)  application  includes  a  multichip  module  (MCM)  consisting  of 
AT28C010  EEPR0M  memory  devices,  one  Xilinx  XC4005A  Field  Programmable  Gate  Array 
(  GA)  and  six  0. 1  juF  decoupling  capacitors.  The  nine  layer  Alumina  hermetic  MCM-C  module  is  44mm  x 
64mm  with  wire  bond  die  interconnects  and  a  95  pin  MCM  I/O  array  (Figure  6-3).  The  MCM  is  mounted  on 
a  smgle  printed  circuit  board  that  mcludes  the  ADTM  connector,  a  DC  to  DC  converter,  I/O  driver  IC's  and  a 
serial  PROM  for  configuring  the  FPGA. 


A  rectangular  shape  for  the  substrate  was  used  to  allow  for  an  optimized  manufacturing  process  This  shape 
provided  the  necessary  wiring  density  for  the  application,  while  also  leaving  minimal  unused  space  on  the  top 
surface  of  the  MCM.  The  substrate  size  and  pin  array  were  the  same  as  the  Sun  Microsystems  MCM  and 
therefore  the  fixtures  developed  for  the  Sun  MCM  could  be  used  for  this  application,  thus  reducing  the  Non 
ecumng  Expenses  (NRE).  As  mentioned  in  the  Sun  Microsystems  application  demo  vehicle  (ADV)  section, 
flie  substrate  was  manufactured  as  multiple  "ups"  (six  in  this  case)  on  the  standard  IBM  127mm  ceramic 
animate ! .  1 Using  six  "ups"  on  the  laminate  left  little  unused  ceramic  and  resulted  in  a  very  cost  efficient 

eS'fu  P6  ***"?*  for  46  devices  were  optimized  with  the  longest  net  length  being  1.76mm.  Also  as 
with  the  Sun  ADV,  the  substrate  groundrules  were  designed  to  provide  a  50  ohm  impedance  match. 

6.4.2  Sector  Activity 


6.4.2.1  Process  Overview 

The  devdopment  of  the  MCM  began  with  a  hardcopy  proposal  from  SM-ALC  for  a  solution  to  their  DTM 
problem.  The  proposal  outlined  the  physical  and  electrical  attributes  of  the  devices  to  be  packaged  on  the 
substrate  This  information,  along  with  the  system  information  including  environmental,  physical  and  power 
allowed  the  application  team  to  generate  a  preliminary  proposal.  Working  with  SM-ALC,  the  application  ’ 
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team  was  able  to  refine  the  proposal  to  provide  SM-ALC  with  a  cost  effective,  efficiently  manufacturable 
MCM  which  met  their  overall  application  requirements  for  the  DTM. 


( 


Figure  6-3  :  Sacramento  ALC  MCM 


Substrate  Size: 

44mm  x  64mm,  9  Layers 

Active  Devices: 

1  Field  Programmable  Gate  Array 
lOEEPROMs 

Passive  devices: 

(6)  O.luF  Capacitors 

Device  Attach: 

Wirebond 

Substrate  I/O: 

95;  Ph  Grid  Array 

Lid  Seal: 

Hermetic 

Design  System: 

Cadence 

6.4. 2.2  Substrate  Design 

Once  the  system  inputs  for  the  refined  MCM  application  were  obtained,  the  next  part  of  the  process  was  to 
get  SM-ALC  set  up  with  the  Cadence  8.0  Design  System.  IBM,  Cadence  and  SM-ALC  worked  together  to 
get  the  8.0  design  system  software  running  at  the  SM-ALC  facility  so  that  the  logic  and  physical  design  could 
be  accomplished.  SM-ALC  performed  both  the  logic  and  physical  designs  using  the  IBM  SCM/MCM 
Design  Kit.  The  detail  of  the  design  process  is  described  within  the  Sun  ADV  section  of  this  report  The 

final  physical  design  was  then  sent  over  the  Internet  by  SM-ALC  and  inputted  into  the  IBM  internal  design 
system  for  design  checking. 

While  the  logic  and  physical  design  was  being  performed  at  SM-ALC,  the  interconnect  test  development  was 
being  done  concurrently  within  the  IBM  Poughkeepsie  facility.  This  concurrent  engineering  activity  allowed 
for  a  reduced  product  cycle  time  as  the  substrates  were  read}'  for  testing  as  soon  as  die  bonding  was 
completed. 
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6.4.2.3  Substrate  Prototype  Build 

The  ceramic  green  sheets  that  were  used  for  the  MCM  substrate  were  personalized  using  a  mechanical  punch 
tool.  Using  a  mechanical  punch  system  allows  for  high  precision  and  rapid  raw  machine  time  for  medium  to 
high  volume  packages.  Once  punched,  the  ceramic  green  sheets  are  screened  with  a  molybdenum  paste.  The 
remainder  of  the  multi-layered  ceramic  build  for  the  substrate  was  the  same  as  the  Sun  ADV  as  described  in 
the  earlier  section,  including  test,  plating  and  pin  braze.  The  one  minor  difference  was  in  plating,  where  a 
thicker  gold  was  used  in  order  to  allow  for  wire  bond  device  interconnection. 

6.4.2.5  Module  Assembly 

After  the  substrate  was  deemed  a  "known  good  substrate"  (KGS)  from  open  and  short  continuity  testing,  the 
EEPROMs  and  FPGA  were  attached  and  wire  bonded  to  the  top  surface  of  the  substrate.  The  capacitors 
were  joined  to  the  surface  of  the  substrate  using  solder  reflow.  The  modules  which  passed  assembly 
verification  testing  were  now  assembled  using  a  ceramic  cap.  Solder  reflow  was  also  used  for  propping  the 
seal  band  during  capacitor  attach.  With  the  seal  band  ready  for  encapsulation,  the  ceramic  caps  were 
assembled  to  the  MCM  and  the  modules  were  tested  for  hermeticity. 

6.4.2.6  Test 

The  signal  architecture  of  the  ADV2  MCM  is  illustrated  in  Figure  6-4  and  shows  five  banks  of  16  bit  wide 
and  64k  deep  Electrically  Erasable  Programmable  Read  Only  Memoiy  (EEPROM)  memoiy  accessed  and 
controlled  by  a  Field  Programmable  Gate  Array  (FPGA).  The  illustrated  4005  Xylinx  FPGA  is  compliant 
with  the  1 149. 1  test  standard.  The  connections  between  the  FPGA  and  the  five  banks  of  EEPROMs  are 
buried  nets  without  physical  probe  access.  The  remainder  of  the  FPGA  leads  are  brought  out  to  the  module 
I/O  for  either  programming  the  FPGA,  observing  the  FPGA  intemal/extemal  states  or  for  use  in  future 
reprogrammed  MCM  configurations.  The  data  is  transferred  into  and  out  of  the  module  using  a  serial 
protocol,  while  the  module  itself  is  brought  to  the  aircraft  by  sneaker  net. 

6.4.2.6.1  Test  Plan 

The  test  plan  for  the  ADV2  module  consists  of  a  parametric  test  for  power  ground  shorts  and  an  assembly 
verification  interconnect  test  which  assures  continuity  of  all  bonds.  Test  data  was  supplied  by  Sacramento  in 
the  form  of  hard  and  softcopy  documents  and  included  device  BSDL  and  Cadence  netlist.  Hardware 
descriptions  for  the  EEPROM  devices  were  obtained  from  hardware  specification  sheets  published  by  the  die 
supplier.  The  interconnect  test  patterns  are  generated  automatically  and  manually  dependent  on  available 

1 149. 1  test  resources.  A  prototype  board,  tested  through  its  TAP  port  using  the  ASSET  tool,  was  to  be  used 
for  database  verification.  The  final  MCM  product  would  be  interconnect  tested  using  the  flexible  hardware 
fixtunng  and  a  DAS9200  based  scan  tester.  Die  supplied  by  the  customer  are  mature  designs  and  are 
considered  as  being  close  to  KGD.  Final  functional  test  is  performed  by  the  customer  using  a  Genrad  tester 
after  insertion  of  the  module  into  its  second  level  system. 

6A.2.6.2  Automatic  Test  Pattern  Generation  (ATPG) 

Assembly  verification  test  for  ADV2  uses  an  automatically  generated  vector  set  and  a  manually  generated  set 
of  vectors.  The  ATPG  portion  of  the  test  checks  for  opens  and  shorts  between  the  FPGA  die  and  the  module 
I/O.  Using  the  FPGA  BSDL  description,  MCM  netlist  and  EEPROM  characteristic  files.  Victory  VITG  is 
used  to  generate  the  SVF  file  containing  the  ATPG  vectors.  The  BSDL  description  was  received  directly 
from  Xylinx  using  their  bulletin  board  service.  Notification  was  made  to  Sacramento  and  Xylinx  concerning 
the  alteration  made  to  correct  their  supplied  version  of  the  FPGA  BSDL.  The  customer  performed  the  MCM 
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physical  design  using  the  Allegro  layout  tool  and  as  such  supplied  the  netlist  directly  to  the  foundry. 
Nomenclature  mismatches  were  not  observed  when  testing  this  MCM. 


Figure  6-4:  ADV2  Module  Signal  Architecture 


6A2.6.3  Manual  TPG 

The  vectors  required  to  test  the  interconnects  to  the  EEPROM  devices  were  manually  generated  from  the 
device  specification  sheets  and  consisted  of  write/read  cycles.  Because  the  EEPROM  design  read/write 
vectors  had  to  be  written  in  128byte  blocks  and  then  electrically  written  into  ROM,  this  process  required  a 
pause  to  be  included  in  the  vector  application  process  due  to  the  write  operation  being  a  relatively  slow 
operation  requiring  several  milliseconds.  The  vector  set  itself  is  similar  to  that  used  for  ADV1  with  the 
difference  being  in  the  number  and  organization  of  the  address  lines  and  not  requiring  a  clock  strobe. 

A  prototype  board  was  used  for  test  data  verification  during  MCM  build  and  proved  valuable  in  finding  out 
problems  before  they  impacted  the  delivery  schedule.  The  board  was  used  to  verify  and  debug  the  power  on 
procedures,  the  FPGA  BSDL  as  well  as  the  exact  protocol  for  EEPROM  write/read  cycles.  The  board  was 
also  used  to  develop  a  test  for  the  few  non-1 149. 1  compliant  signal  lines  on  the  FPGA.  A  null  (or  all  zeros) 
program  was  loaded,  using  the  serial  input  and  control  signals  until  the  8k  FPGA  program  block  was  filled. 
The  test  observed  the  program  completion  signals  for  activity  following  the  loading  of  a  FPGA  program 

thereby  establishing  the  connectivity  of  the  targeted  signal  lines. 
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6.4.2.6.4  MCM  Interconnect  Test 

Interconnect  test  coverage  for  the  ADV2  module  is  presented  in  Table  6-4  and  is  98.4%  overall  and  is  100% 
for  all  signal  lines.  The  test  generation  process  and  integration  with  the  test  fixture  went  veiy  smoothly  and 
resulted  in  the  ADV2  MCM  assembly  verification  testing  to  be  completed  on  schedule.  With  regard  to  the 
benchmarking  data  presented  in  Figure  3-14,  Section  3.5,  Data  Integrity,  additional  effort  was  required  for 
debug  of  the  BSDL  and  test  procedures  prior  to  receipt  of  the  MCM,  underscoring  the  need  for  complete  and 
verified  data.  One  benchmark  category.  Test  Pattern  Generation  (TFG),  was  right  on  the  target  of 
approximately  eight  days.  The  contributors  to  the  success  of  this  task  were  a  single  nomenclature,  timely 
receipt  of  all  required  information,  access  to  a  prototype  board  and  our  increased  experience  in  applying 
manually  generated  patterns  through  Victory  and  the  1 149. 1  test  architecture. 


OPEN  /  SHORT  COVERAGE 

VITG 

VITG  +  VCCT 

Fully  covered 

70 

113 

Partially  covered 

0 

0 

Shorts  covered 

43* 

0 

Some  opens  covered 

2 

2 

Not  covered 

0 

2 

Covered  by  TAPIT 

5 

5 

(Number  of  covered  nets/total  nets)  x  100 
*Deratedby  100% 

64.1% 

98.4% 

Partially  covered  nets  may  have  an  uncovered  branch  or  may  be  single  ended. 

A  single  ended  net  refers  to  a  net  having  only  one  observe/stim  point. 

Partially  covered  nets  are  derated  by  the  fraction  of  branches  not  covered 

Table  6-4:  ADV2  Interconnect  Test  Coverage 


6.4.3  Conclusion 

The  Sacramento  Air  Force  Logistics  Center  MCM  application  was  successfully  built  and  all  interconnects 
were  verified  using  electrical  testing.  Although  a  straightforward  design,  the  application  provided  the 
opportunity  to  demonstrate  acceptance  of  a  completed  physical  design  into  the  IBM  design  system  IBM 
personnel  worked  directly  with  SM-ALC  to  develop  their  physical  design  capabilities  on  the  Cadence  system. 

The  substrate  build  used  conventional  alumina  thick  film  materials  and  was  manufactured  on  the  high  volume 
lrne  m  the  foundry,  demonstrating  low  volume  build  capability  in  the  line.  The  module  used  tooling  and 
fixtures  put  in  place  for  the  Sun  ADV  form  factor,  thereby  helping  to  reduce  the  NRE  expenses.  The  module 
was  fabricated  using  off  the  shelf  wire  bond  die,  which  were  known  to  function  as  required,  reducing  the  risk 

of  assembling  bad  die  to  the  MCM. 

The  customer  was  able  to  assemble  the  completed  module  to  the  test  board  developed  for  the  project  and 
functionally  test  the  module. 
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6.5  NATIONAL  SEMICONDUCTOR 

6.5.1  Product  Development 

6.5.1. 1  Business  Development  Description 

The  third  application  demonstration  vehicle  was  designed  and  built  for  National  Semiconductor,  based  on  a 
logic  design  provided  by  National.  The  end  user  for  the  module  is  E-SYSTEMS,  who  will  use  ihe  module  as 
a  Digital  Signal  Processor  for  a  SATCOM  modem.  The  use  of  high  density  flip  chip  technology  provides  a 
conduit  for  breaking  up  a  very  large  die  into  multiple,  smaller,  higher  yielding  die  which  can  be  fully 
interconnected  without  losing  any  circuit  capacity.  National  Semiconductor  required  high  density  I/O  on  both 
the  chip  to  substrate  and  substrate  to  board  connections  and  both  were  achievable  using  Flip  flhip  and  Ball 
Grid  Array.  National  Semiconductor  approached  the  IBM  foundry  through  the  Request  for  Sizing  process, 
describing  the  technology  requirements  of  the  package.  The  foundry,  through  the  ASEM  team,  then  worked 
with  National  to  develop  the  current  design  configuration. 

6.5.1. 2  Document  of  Execution 

The  National  Semiconductor  application  was  the  first  of  the  ADV’s  to  be  designed  and  built  under  ISO  9000 
certification.  A  Document  of  Execution  is  required  for  all  new  programs  and  documents  the  program  plan 
and  module  description  in  detail.  No  new  product  can  be  built  without  the  document  in  place.  Since  this  is  a 
prototype  build  only,  the  appropriate  Prototype  document  format  was  used.  The  document  was  generated  and 
provided  to  National  for  review.  Upon  approval,  it  was  inputted  into  the  foundry,  and  has  been  updated 
according  to  a  predefined  schedule.  The  Program  Manager  is  solely  responsible  for  the  updates. 

6.5.1. 3  Hardware  Description 

The  design  consisted  of  four  Custom  Logic  Array  (CLAy)  devices  on  a  32mm  square  substrate.  The  four  die 
on  the  MCM  are  identical,  and  are  wired  in  a  symmetrical  pattern  that  provided  the  opportunity  to  wire  the 
substrate  using  tighter  line  widths  and  spacings  than  conventional  thick  film  modules.  The  off  module  I/O 
are  through  a  Ball  Grid  Array,  with  a  pitch  of 0.050",  providing  a  total  of  625  I/O  on  the  32mm  substrate. 

The  lid  design  is  a  standard  aluminum  non-hermetic  cap  with  no  thermal  enhancement. 
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6.5.2  Sector  Activity 

6.5.2.1  Process  Overview 

piSSf  A^Z^f,0r^TeSt?i  Pr°P0SalS  f0r  the  CLAy  MCM  ttrou8h  BM  R^ucst  for  Sizing 

process.  A  number  of  module  options  were  proposed  in  both  thick  film  (MCM-C)  and  thin  films  (MCM-D). 

When  the  decision  was  made  to  use  Thick  film  technology,  there  was  considerable  interaction  between  the 

“*  “T"1  ,Se“conductor-  H”**  to  interaction,  the  cum*  wiring 
fcSS  °nce  tilts  was  completed,  the  project  proceeded  along  die  same  path  as  die  Sun 

6.5.2.2  Substrate  Design 
6.5.2.2.1  Design  Support 

MCM  made  f0r  3  Veiy  'mique  substrate  design-  Since  each  ofthe  die  were 
Klenhcal,  and  the  die  to  die  connections  were  along  parallel  paths,  the  substrate  could  be  wired  by  straight 

module  ConventioMTthS  fit*5" XY  Cross°vers'  Figure  6*6  represents  one  of  the  rows  of  wiring  in  the 

flkn  SCTeemng  for  la3'ers  uses  separate  wiring  planes  for  X  and  Y  wiring 
between  plane  pairs.  This  standi ’triplate’  stru^rl  ^ 
f°"  *“  M<TM> resulted  m  a  cross  section  of  42  layers.  By  screening  X  and  Y  wiring  chZels 
the  same  layer  and  stacking  three  wiring  layers  together  before  adding  a  reference  plane,  and  by  rtducktg 
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the  wiring  pitch  from  0.020"  to  0.010",  the  cross  section  was  reduced  to  20  layers.  The  screening  technology 
required  to  achieve  this  is  similar  to  what  is  used  on  redistribution  layers,  except  the  redistribution  lines  are 
generally  much  shorter.  The  concern  was  whether  the  longer  line  lengths  would  result  in  a  screening  problem 
in  manufacturing. 


6*5.2*2.2  Logic  Entry  Level 

The  actual  substrate  design  was  done  on  a  combination  of  Cadence  Allegro  and  IBM's  IGS-2  design  systems 
The  substrate  logic  design  was  completed  by  National  Semiconductor  on  a  Cadence  design  system,  but 
because  of  die  need  to  route  the  I/O's  on  a  straight  line  and  fine  pitch  grid,  the  module  was  100%  manually 
routed.  Design  data  was  sent  on  a  tape  in  the  form  of  an  ASCII  netlist. 

6.5.2.2.3  Release 

The  substrate  design  data  proceeded  through  the  standard  IBM  Direct  release  procedure,  with  post  processing 
of  the  design  data  into  data  that  was  used  to  generate  the  Molybdenum  masks  for  feature  screening.  The 
esign  data  was  also  used  to  generate  the  punch  data.  The  design  data  was  used  to  generate  the  CADAM 
awmgs  of  the  substrate  cross  section  and  the  top  and  bottom  drawings  required  by  the  module  assembly 
area.  The  drawings  were  given  corporate  Part  Numbers  and  are  subject  to  the  same  change  procedures  as 
described  m  the  Sun  Microsystems  section. 
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6.5.23  Substrate  Prototype  Build 

substrate  was  fabricated  in  the  manufacturing  line  using  conventional  punch  and  screen 
methods.  The  complexity  of  the  finer  wiring  grid,  and  the  inclusion  of  X  and  Y  wiring  patterns  on  the  same 
ayer  caused  some  concern  on  the  ability  to  yield  the  substrates  to  an  acceptable  level.  A  "send  ahead"  lot  of 
substrates  was  manufactured  to  determine  if  the  distortion  of  the  substrates  met  the  specification,  essential  for 
lip  Chip  modules.  If  there  was  a  distortion  problem,  the  lamination  pressure  can  be  adjusted  in  the  following 
build  to  compensate  for  the  problem.  In  this  case,  the  distortion  was  within  spec  and  the  remainder  of  the 
parts  were  released  to  manufacturing. 

After  sintering,  a  sample  of  10  parts  were  submitted  for  electrical  verification  and  open/shorts  testing.  The 
electrical  verification  compares  the  customer  netlist  to  the  actual  hardware  build  to  confirm  the  design  is 
correct.  The  CLAy  MCM's  passed  electrical  verification.  The  opens/shorts  test  did  confirm  a  yield  problem 
wth  the  substrates,  consisting  of  a  small  number  of  short s  on  approximately  40%  of  the  parts.  Diagnostics  of 
the  substrates,  consisting  of  sectioning  through  the  substrate  layer,  showed  line  bleeding  between  adjacent 
lines.  This  was  attributed  to  the  location  of 'tabs',  which  hold  the  screening  mask  together  on  long  lines  The 
tabs  were  placed  adjacent  to  each  other  in  the  mask.  Staggering  the  tabs  would  eliminate  the  problem  and 
bring  the  yield  to  an  acceptable  level. 


P16  P3?1 lY6re  *en  subnutted  t0  Ae  Piling  sector  where  a  layer  of  electroless  Nickel  (Boron)  was  plated  on 
e  Molybdenum  and  diffused.  This  was  followed  by  a  thin  layer  of  gold,  which  was  also  diffused.  The  gold 
thickness  is  minimized  in  order  to  limit  the  amount  of  Gold/Tin  intermetallics  in  the  flip  chip  solder  joint 
The  part  is  now  ready  for  device  joining 


6.S.2.4  Flip  Chip  Bumping 

National  Semiconductor  used  the  existing  wire  bond  die  design  and  modified  it  for  flip  chip  pads.  The  design 
used  an  array  pattern  of  pads,  with  off  module  signals,  power,  and  ground  around  the  periphery  of  the  array 
and  chip  to  chip  signals  inside.  National's  design  system  laid  out  the  flip  chip  pad  design  in  a  periodicity  of* 
226  microns.  This  is  not  consistent  with  the  IBM  substrate  design  periodicity  of 225  microns,  but  the 
cumulative  error  was  not  sufficient  to  cause  misalignment  of  the  die  to  the  substrate.  National  provided 
softcopy  data  of  the  pad  layouts,  as  well  as  the  die  layouts  on  the  wafer.  Two  sets  of  wafers  were  prepared  by 


Wafers  with  capture  pads  and  no  passivation 

Wafers  with  capture  pads  and  passivation  applied  by  National 


The  purpose  of  the  two  sets  of  wafers  was  to  evaluate  whether  the  National  applied  passivation,  which  could 
be  a  potential  cost  reduction,  would  perform  as  well  as  the  IBM  applied  passivation.  The  passivation  was 
evaluated  based  on  physical  strength  and  mode  of  failure  after  tensile  pull  of  the  die  off  the  module  Since 

n° IBM  fedlStnbutl0n  required  for  to  module’  electrical  analysis  of  the  flip  chip  bumping  was  not 


The  process  flow  for  the  wafers  is  as  follows: 

•  Receive  wafers  from  National  Semiconductor 

•  Apply  passivation  (unpassivated  wafers) 

•  Open  passivation  and  apply  Ball  Limiting  Metallization  (BLM) 

•  Apply  Lead/Tin  Solder 

•  Reflow  to  form  Flip  Chip  ball 

•  Inspect  Solder  Balls 

•  Dice  and  Pick  die 
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6.5.2.5.1  Cap/Heatsink  Development 

Due  to  the  low  power  dissipation  (0.5  W/Chip,  2.0W/Module)  of  the  CLAy  MCM,  the  module  did  not 
require  advanced  cooling  techniques.  After  the  die  were  Flip  Chip  attached  to  the  module,  a  cap  was  placed 
over  the  die  Thermal  grease  and  a  heatsink  were  not  required.  The  32mm  module  design  allowed  for  the  use 
of  a  standard  cap,  which  has  been  used  on  prior  MCM  and  SCM  projects.  The  absence  of  decoupling 
capacitors  eliminated  the  need  for  recesses  in  the  cap  (capacitors  are  higher  than  the  bumped,  attached  die 
and  therefore  require  unique  recesses)  and  the  cap  could  be  used  'as  procured'.  The  cap  was  attached  to  the 
module  using  a  Silicone  based  epoxy.  A  unique  marking  pattern  was  designed  for  the  cap,  incorporating  the 
National  Semiconductor  logo,  as  well  as  the  ARPA  and  IBM  logo's. 


6.5.2.5.2  Release 

TJe  drawings  of  the  module  were  created  following  the  completion  of  the  cross  section  and  delivery  of  the 
chip  thickness  specifications  from  National  Semiconductor.  Since  the  cap  was  already  designed  and 
fabricated,  only  the  substrate  thickness  and  chip  thickness  had  to  be  defined.  The  drawings  were  generated 
and  provided  to  the  module  test  socket  engineering  group  and  the  Bond  and  Assembly  group.  Control  of  the 
document  was  maintained  through  IBM's  internal  part  number  system.  An  official  change  to  the  module 
drawing  required  a  design  review  and  awareness  of  all  users  of  the  module  assembly  drawing. 


6.52.6  Module  Assembly 

Die  assembly  of  the  flip  chip  bumped  die  was  verified  using  a  sample  of  mechanically  good  die  from 
National  Semiconductor.  The  first  step  in  the  assembly  process  was  to  establish  a  furnace  profile  for  the 
specific  National  substrate.  Thickness  and  metal  loading  within  the  substrate  can  affect  the  top  surface 
temperature  of  the  module  during  reflow,  so  the  profile  was  established  using  a  thermocouple  instrumented 
CLAy  substrate.  Following  the  definition  of  the  profile,  the  mechanicaUv  good  die  were  placed  on  the 
substrate  using  flux  The  split  optics  of  the  place  tool  confirmed  that  the  Flip  Chip  pads  designed  by  National 
Seiiuconductor  matched  the  pads  designed  on  the  substrate.  After  reflowing  the  die  to  the  substrate,  they  were 
pulled  off  to  check  for  wettability.  Each  microsocket  (flip  chip  pad)  must  be  wetted  before  the  Flip  chip 
attach  process  is  confirmed  as  acceptable.  The  failure  mode  and  pull  strength  are  also  checked  against  a 
specification  to  insure  there  are  no  unusual  failure  mechanisms.  In  the  case  of  the  wafers  passivated  by 
National  Semiconductor,  the  pull  strengths  were  well  above  the  minimum  pull  specification  and  all  the  pulls 
were  ductile  taffy  pulls,  which  is  the  best  condition. 


After  the  electrically  good  die  were  assembled  to  the  electrically  good  substrates 
attached  to  the  top  of  die  module  to  protect  the  die.  The  lid  was  attached  with  an 
die  underfill  was  required  because  of  the  low  power  requirements  of  the  module, 
with  the  appropriate  design  through  a  stencil. 


,  a  non  hermetic  lid  was 
epoxy.  No  thermal  grease 
The  lid  was  then  marked 


or 


The  last  phase  of  the  assembly  process  was  the  Ball  Grid  Airay  attach.  Eutectic  Lead  Tin  solder  paste  is 

°n*ePads  on  *e  bottom  surface  of  toe  substrate  and  the  module  is  placed  in  the  fixture  with 
90Pb/Sn  balls.  The  assembly  is  then  reflowed  through  a  furnace,  and  the  eutectic  forms  a  fillet  around  the 
base  ofthe  solder  balls.  The  ball  does  not  reflow  during  the  process,  maintaining  its  shape  for  assembly  to  the 
card.  The  module  is  then  removed  from  the  fixture  and  inspected. 


The  electrically  good  modules  were  then  shipped  to  National  Semiconductor  for  test. 
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632.1  Test 

«  atli°na!  ^CM  propoflwas  reviewed  for  appropriate  testability  before  the  final  National  sihcon  design 
as  fmalized  ^““endations  were  made  concerning  known  good  die,  the  impact  of  die  yield  on  MCtvl 
p  ototype  jaeld  and  MCM  dia^iostics.  Since  the  customer  was  adding  new  devices  and  wiring  to  an  existing 
mature  FPGA  die  design,  KGD  concerns  were  focused  primarily  on  ensuring  complete  test  coverage  of  the  * 
new  die  features.  The  customer  took  our  recommendations  under  advisement  and  implemented  a  die  test 
procedure  which  enabled  complete  testing  of  all  new  die  features.  The  test  procedures  which  are  used  to 
ensure  a  known  good  substrate  were  reviewed  with  the  customer. 

6.5.2.6.1  Test  Plan 

National  will  produce  known  good  die  for  the  module  by  performing  wafer  level  test  in  two  stages.  The  first 

nSer/nC^Ct  y  *5?  '1S&i  fTr^r 6xisting  FPGA  production  Part-  The  second  stage  of  the  test  uses  the 

new  I/O  and  a  subset  of  the  original  I/O  and  performs  checks  on  the  operation  of  the  new  circuitry  and  wiring 

ofUvo  major  ^p™^smterCOnneCt  311(1  fmctional  testis  of  assembled  modules.  The  testing  will  consist 

Parametric  test  establishing  correct  power/ground  resistance  levels  and  ESD  signal  diode  continuitv. 
functional  Test  using  a  Trillium  tester  and  proprietary  FPGA  tests. 

kjTJ  of  electncal  testmg  at  IBM  a  sample  of  mechanically  good  parts  were  assembled  at  IBM,  the  die  were 
pulled  offthe  substrates,  and  the  flip  chip  pads  were  inspected  for  wettability  The  parts  built  with  the  Plan  of 

6.5.3.  Conclusion 

I?®  ^°naI  Se™con<foctor  CLAy  MCM  was  successfully  fabricated  using  the  IBM  Microelectronics  thick 
film  alurmna  and  Flip  Chip  Interconnect  processes.  The  Substrate  was  confirmed  as  good  through  electrical 
testing  which  compared  the  fabricated  substrate  with  the  National  Semiconductor  netlist,  and  also  confirmed 
Sh°T  ^  dielmterconnect  t0  A*  substrate  was  not  electrically  verified  by  IBM,  but 
wetted^ads ^  °n  mechamcally  g°°d  samples  confirmed  that  the  process  yielded  100% 

The  electrical  analysis  of  the  substrate  was  extensive  in  order  to  guarantee  that  the  design  would  meet  the 

^^requmnients.  The  manufacture  of  the  substrate  was  also  complicated  by  the  finTline  screening  and 

l^mina  tiTJ6  ^  bulWere  subsequently  understood  and  will  be  corrected  in  future  builds^This 

learning  will  be  applied  to  future  fine  line  products. 

5? assembly  on  die  designed  for  area  array  by  National  Semiconductor  was  also  successfully 

“cluff  *e  wluch  wer®  passivated  by  National.  National  successfully  transferred  the  flip  chip 

hnmn^f0”  t  V?,?  ^  s,uccessfUIIy  “^orated  into  the  top  surface  substrate  design  and  the  FlipPChip 
bumping  masks-  The  die  attach  process  was  verified  on  mechamcally  good  samples,  providing  a  high  P 

confidence  that  the  electrically  good  samples  were  100%  interconnected.  The  electrically  good  samples  have 
been  provided  to  National,  and  electrical  testing  is  currently  in  progress.  P 


6-26 


6.6  APPLICATION  TASK  CONCLUSIONS 

ti°“  >*?8d  demonstrated  different  levels  of  complexity  in  the  design,  build,  and  test  of 
c  pm  e.  11  of  the  module  designs  successfully  passed  interconnect  testing  at  the  module  level. 

T^e  sun  application  used  conventional  substrate  technolog)'  in  a  standard  size,  but  demonstrated  the  ability 
of  the  Cadence  design  system  to  accept  Sun's  logic  design  and  convert  it  into  a  physical  design  The 

BuSn,t°  T**3?1  ^  aMity  t0  apply  FIiP  ChiP  ^logy  to  die  designator  wire  bond 
significant  accomplishment  in  the  Sun  apphcation  is  the  demonstration  of  IBM's 
Known  Good  Die  process  for  flip  chip  bumped  die.  Using  Single  Chip  Modules  (SCM),  designed  to  match 

mSpSI  “1Stm8  Vadn*  a”d  11X00  SCM,S' for  use  on  tile 

The  Sacramento  AFB  application  made  use  of  "off  the  shelf’  die  technology  from  OEM  suppliers 

^  tefnoIogy’ standard  fomdO'  substrate  technology  and  sizes.  The  significant 

?  W3S  theucu"tomers  ablhty t0  .«*  d^ign  kit  to  do  the  complete  physical  design,  and  to  have 

e  IBM  tools  accept  the  design  and  turn  it  into  a  fully  functional  module. 

The  National  SeuuconductorCLAy  MCM  used  fine  line  screening  in  the  substrate  and  die  which  were 
deseed  for  flip  chip  by  National  Semiconductor.  The  design  demonstrated  a  logic  entry  point  into  the  IBM 

design  system,  but  required  a  custom  design  to  route  the  unusual  wiring  pattern. 

tp^ino^  substrate  designs  werevahdated  by  comparing  the  finished  substrate  to  the  netlist  by  electrically 
g  a  sample  of  substrates.  The  die  attach  was  confirmed  on  both  the  Sun  and  Sacramento  MCM's 

SoSon' STieMteS^  T!ie  Na?0nal  d6Sign  W3S  Verified  by  valldatm§  assembly  process  through 

inspection  of  the  solder  joints.  In  each  case  the  requirement  to  provide  a  module  guaranteed  through 
interconnect  testing  was  successfully  accomplished. 
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7.0  OVERALL  ASEM  CONTRACT  CONCLUSIONS 

All  contract  tasks  were  completed  successfully,  on-time,  and  to  cost.  Significant  progress  was  also 
shown  towards  achieving  the  global  ARPA  objectives  for  the  ASEM  program.  Detailed 
conclusions  for  each  technical  area  are  at  the  end  of  the  respective  sections. 

The  main  thrust  of  additional  efforts  should  be  in  developing  applications  that  map  well  to  MCMs 
and  provide  significant  product  advantages. 

Some  MCM  support  issues,  while  improving  still  need  attention.  To  list  them: 

•  Increased  availability  and  quality  of  Known  Good  Die 

•  Increased  availability  of  softcopy  descriptions  of  the  die,  (in  the  DIE  format) 

•  Increased  focus  on  data  integrity  issues  of  data  consistency  (e.g.  BSDL  to  netlist 
nomenclature  consistency)  and  of  design  data  management.  This  probably  involves 
increased  integration  of  design  process  activity  within  fuller  function  framework 
environments. 

•  Continued  focus  on  fabrication,  assembly,  and  test  cost  reduction 

•  Continued  focus  on  interface  standards  (e.g.  EDIF-PCB  extensions  for  MCMs) 

•  Continued  focus  on  standardizing  substrate  configurations  and  footprint  definitions 

•  Continued  infrastructure  support  to  insure  a  forum  for  discussion  of  critical  MCM 
issues 


End  of  ASEM  Final  Technical  Report 
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